在 RHEL 中配置身份验证和授权
使用 SSSD、authselect 和 sssctl 配置身份验证和授权
摘要
authselect
和 sssctl
等工具支持您配置 SSSD、可插拔验证模块(PAM)和名称服务交换机(NSS)。
使开源包含更多
红帽承诺替换我们的代码、文档和网页属性中存在问题的语言。我们从这四个术语开始: master、slave、blacklist 和 whitelist。这些更改将在即将发行的几个发行本中逐渐实施。如需了解更多详细信息,请参阅 CTO Chris Wright 信息。
在身份管理中,计划中的术语变化包括:
- 使用 block list 替换 blacklist
- 使用 allow list 替换 whitelist
- 使用 secondary 替换 slave
master 会根据上下文被替换为其他更适当的术语:
- 使用 IdM server 替换 IdM master
- 使用 CA renewal server 替换 CA renewal master
- 使用 CRL publisher server 替换 CRL master
- 使用 multi-supplier 替换 multi-master
对红帽文档提供反馈
我们感谢您对我们文档的反馈。让我们了解如何改进它。
根据具体内容提交评论
- 查看 Multi-page HTML 格式的文档,并确保在页面完全加载后看到右上角的 反馈 按钮。
- 使用光标突出显示您要评论的文本部分。
- 点击在高亮文本旁的 添加反馈 按钮。
- 添加您的反馈并点 Submit。
通过 Bugzilla 提交反馈(需要帐户)
- 登录到 Bugzilla 网站。
- 从 Version 菜单中选择正确的版本。
- 在 Summary 字段中输入描述性标题。
- 在 Description 字段中输入您的建议以改进。包括文档相关部分的链接。
- 点 Submit Bug。
第 1 章 使用 authselect 配置用户身份验证
authselect
是一个实用程序,允许您通过选择特定的配置集来配置系统身份和身份验证源。配置集(profile)是一组文件,描述生成的可插拔验证模块 (PAM) 和网络安全服务 (NSS) 配置。您可以选择默认的配置集或创建自定义配置集。
1.1. authselect 的作用
您可以使用 authselect
在 Red Hat Enterprise Linux 8 主机上配置用户身份验证。
您可以通过选择一个可用的配置集来配置身份信息和验证源和供应商:
-
默认
sssd
配置集为使用 LDAP 身份验证的系统启用系统安全服务守护进程 (SSSD)。 -
winbind
配置集为直接与 Microsoft Active Directory 集成的系统启用 Winbind 实用程序。 -
nis
配置集确保了与传统网络信息服务 (NIS) 系统的兼容性。 -
minimal
配置集只用于直接来自系统文件中的本地用户和组,它允许管理员删除不再需要的网络身份验证服务。
在为给定主机选择了一个 authselect
配置集后,配置集将应用于登录到主机的每个用户。
红帽建议,在半集中式身份管理环境中使用 authselect
。例如,如果您的组织使用 LDAP、Winbind 或 NIS 数据库来验证用户以在您的域中使用服务。
如果出现以下情况,您不需要使用 authselect
:
-
您的主机是 Red Hat Enterprise Linux 身份管理(IdM)的一部分。使用
ipa-client-install
命令将您的主机加入 IdM 域会自动在主机上配置 SSSD 身份验证。 -
您的主机通过 SSSD 成为活动目录的一部分。调用
realm join
命令将您的主机加入 Active Directory 域会自动在您的主机上配置 SSSD 身份验证。
红帽建议不要更改由 ipa-client-install
或 realm join
配置的 authselect
配置文件。如果您需要修改它们,请在进行任何修改之前显示当前的设置,以便在需要时将它们恢复回来:
$ authselect current
Profile ID: sssd
Enabled features:
- with-sudo
- with-mkhomedir
- with-smartcard
1.1.1. authselect 修改的文件和目录
在以前的 Red Hat Enterprise Linux 版本中使用的 authconfig
实用程序会创建并修改许多不同的配置文件,从而使故障排除变得更加困难。authselect
简化了测试和故障排除过程,因为它仅修改以下文件和目录:
| GNU C 库和其他应用使用此名称服务交换机 (NSS) 配置文件来确定从中获取一系列类别中的名称服务信息的来源,以及顺序。每个类别的信息都由一个数据库名来标识。 |
| Linux-PAM(可插拔验证模块)是处理系统中应用程序(服务)验证任务的模块系统。验证的特性是动态可配置的:系统管理员可以选择如何单独提供服务提供应用程序验证用户。
这些文件还包含以下信息:
|
|
此目录包含 |
1.1.2. /etc/nsswitch.conf
中的数据提供程序
默认 sssd
配置集通过在 /etc/nsswitch.conf
中创建 sss
条目将 SSSD 设置为信息源:
passwd: sss files group: sss files netgroup: sss files automount: sss files services: sss files ...
这意味着,如果请求了有关这些项目之一的信息,系统首先会查找 SSSD:
-
passwd
用于用户信息 -
group
用户组群信息 -
netgroup
用于 NISnetgroup
信息 -
automount
用于 NFS 自动挂载信息 -
services
用于有关服务的信息
只有在 sssd
缓存和提供身份验证的服务器上找不到请求的信息,或者 sssd
没有运行时,系统才会查看本地文件,即 /etc/*
。
例如,如果请求有关用户 ID 的信息,则首先在 sssd
缓存中搜索用户 ID。如果未在此处找到,则会查阅 /etc/passwd
文件。类似地,如果请求用户的组从属关系,则首先在 sssd
缓存中搜索它,并且仅在未找到时搜索 /etc/group
文件。
实际上,本地文件
数据库通常不会被查阅。最重要的例外是 root
用户,它永远不会由 sssd
处理,而是由文件
处理。
1.2. 选择 authselect 配置集
作为系统管理员,您可以为特定主机选择 authselect
工具的配置集。该配置集将应用于登录到主机的每个用户。
先决条件
-
运行
authselect
命令需要root
凭证
流程
选择适合您的身份验证供应商的
authselect
配置集。例如,若要登录到使用 LDAP 的公司网络,请选择sssd
。# authselect select
sssd
(可选)您可以在
authselect select sssd
或authselect select winbind
命令中添加以下选项来修改默认配置集设置,例如:-
with-faillock
-
with-smartcard
-
with-fingerprint
-
要查看可用选项的完整列表,请参阅 将脚本从 authconfig 转换到 authselect
或者 authselect-migration (7)
手册页。
在完成 authselect select
过程前,请确定正确配置了与您的配置集相关的配置文件。例如,如果 sssd
守护进程没有正确配置并处于活动状态,则运行 authselect select
会导致只有本地用户可以使用 pam_unix
进行身份验证。
验证步骤
验证
/etc/nsswitch.conf
中是否存在 SSSD 的sss
条目:passwd: sss files group: sss files netgroup: sss files automount: sss files services: sss files ...
在
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.3. 修改可用的 authselect 配置集
作为系统管理员,您可以修改一个默认配置集使其适合您的需要。
您可以修改 /etc/authselect/user-nsswitch.conf
文件中的任何项目,但以下除外:
-
passwd
-
group
-
netgroup
-
automount
-
services
随后运行 authselect select
profile_name
会导致将允许的更改从 /etc/authselect/user-nsswitch.conf
传输到 /etc/nsswitch.conf
文件。不可接受的更改会被默认配置集的配置覆盖。
不要直接修改 /etc/nsswitch.conf
文件。
流程
选择一个
authselect
配置集,例如:#
authselect select
sssd
-
按照您所需的更改编辑
/etc/authselect/user-nsswitch.conf
文件。 应用
/etc/authselect/user-nsswitch.conf
文件中的更改:#
authselect apply-changes
验证步骤
-
查看
/etc/nsswitch.conf
文件,以验证/etc/authselect/user-nsswitch.conf
中的更改是否已在此传播。
其它资源
1.4. 创建并部署您自己的 authselect 配置集
作为系统管理员,您可以通过生成一个默认配置集的自定义副本来创建和部署自定义配置集。
这在修改一个现成的 authselect 配置集不足以满足您的需要时特别有用。当您部署自定义配置集时,配置集将应用于记录到给定主机上的每个用户。
流程
使用
authselect create-profile
命令创建自定义配置集。例如,基于可用的sssd
配置集创建一个名为user-profile
的自定义配置集,您可以自行在/etc/nsswitch.conf
文件中配置项目:#
authselect create-profile
user-profile
-bsssd
--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
文件的副本。-
配置
/etc/authselect/custom/user-profile/nsswitch.conf
文件。 运行
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
数据库中查找。编辑
/etc/nsswitch.conf
文件,修改以下行:hosts: files
基于
sssd
创建自定义配置集,它排除了对/etc/nsswitch.conf
的更改:#
authselect create-profile
user-profile
-bsssd
--symlink-meta --symlink-pam选择配置集:
#
authselect select
custom/user-profile
(可选)检查是否已选择自定义配置集
-
根据所选的
sssd
配置集创建/etc/pam.d/system-auth
文件 原封不动保留
/etc/nsswitch.conf
中的配置:hosts: files
注意运行
authselect select
sssd
将会产生hosts: files dns myhostname
-
根据所选的
其它资源
1.5. 将脚本从 authconfig
转换为 authselect
如果您使用 ipa-client-install
或 realm join
加入域,您可以在脚本中安全地删除任何 authconfig
调用。如果不可能,将每个 authconfig
调用替换为其等同的 authselect
调用。要做到这一点请选择正确的配置集和适当的选项。另外,请编辑必要的配置文件:
-
/etc/krb5.conf
-
/etc/sssd/sssd.conf
(用于sssd
配置文件)或/etc/samba/smb.conf
(用于winbind
配置集)
authconfig 选项和 authselect 配置文件的关系 以及 与 authconfig 选项等价的 Authselect 配置文件选项 显示了与 authconfig
选项等价的 authselect
。
表 1.1. authconfig 选项与 authselect 配置集的关系
authconfig 选项 | authselect 配置集 |
---|---|
|
|
|
|
|
|
|
|
|
|
表 1.2. authselect profile 选项等同于 authconfig 选项
authconfig 选项 | authselect 配置集特性 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
与 authconfig 命令等效的 authselect 命令示例显示了,Kickstart 对 authconfig
的调用转换为 Kickstart 对 authselect
的调用的示例。
表 1.3. 与 authconfig 命令等同的 authselect 命令示例
authconfig 命令 | authselect 等同的命令 |
---|---|
|
|
|
|
|
|
|
|
1.6. 其它资源
第 2 章 了解 SSSD 及其优势
系统安全服务后台程序 (SSSD) 是一种用于访问远程目录和身份验证机制的系统服务。以下章节概述了 SSSD 的工作原理、使用它的益处、如何处理配置文件,以及您可以配置的身份和身份验证提供程序。
2.1. SSSD 如何工作
系统安全服务后台程序 (SSSD) 是一种系统服务,可让您访问远程目录和身份验证机制。您可以把一个本地系统(一个 SSSD 客户端 )连接到外部后端系统(一个 provider)。
例如:
- 一个 LDAP 目录
- 一个 Identity Management(IdM)域
- 一个 Active Directory(AD)域
- 一个 Kerberos realm
SSSD 分为两个阶段:
- 它将客户端连接到远程供应商以检索身份和验证信息。
- 它使用获得的验证信息来创建客户端用户和凭证的本地缓存。
然后,本地系统中的用户可以使用保存在远程供应商的用户帐户进行身份验证。
SSSD 不会在本地系统上创建用户帐户。但是,可将 SSSD 配置为为 IdM 用户创建主目录。创建后,当用户注销时,IdM 用户主目录及其在客户端中的内容不会被删除。
图 2.1. SSSD 如何工作

SSSD 还可以为多个系统服务提供缓存,如名称服务交换机 (NSS) 或可插拔验证模块 (PAM)。
2.2. 使用 SSSD 的好处
使用系统安全服务后台程序 (SSSD) 在用户身份检索和用户身份验证方面具有多个益处。
- 离线验证
- SSSD 可选保留一个从远程供应商获取的用户身份和凭证缓存。在此设置中,如果用户已在会话开始时对远程提供程序进行身份验证一次 - 即使远程提供程序或客户端脱机,也可以成功验证资源。
- 单一用户帐户:提高身份验证过程的一致性
使用 SSSD 时,不需要同时维护中央帐户和本地用户帐户进行离线身份验证。条件为:
- 在特定的会话中,用户必须至少登录一次:当用户第一次登录时,客户端必须连接到远程供应商。
SSSD 中必须启用缓存。
在没有 SSSD 时,远程用户通常会有多个用户帐户。例如,要连接到虚拟专用网络(VPN),远程用户需要有一个本地系统帐户,以及另外一个 VPN 帐户。在这种情况下,您必须首先在私有网络中进行身份验证,以便从远程服务器获取用户,并在本地缓存用户凭证。
使用 SSSD 时,利用缓存和离线身份验证,远程用户只需向本地机器验证即可连接到网络资源。然后,SSSD 维护其网络凭证。
- 这可以减少身份和验证提供程序上的负载
- 在请求信息时,客户端首先检查本地 SSSD 缓存。只有在缓存中没有这些信息时,SSSD 才会联系远程供应商。
2.3. 基于每个客户端有多个 SSSD 配置文件
SSSD 的默认配置文件为 /etc/sssd/sssd.conf
。除了这个文件外,SSSD 还可以从 /etc/sssd/conf.d/
目录中的所有 *.conf
文件中读取其配置。
这个组合允许您在所有客户端中使用默认 /etc/sssd/sssd.conf
文件,并在以后的配置文件中添加附加设置,以针对每个客户端单独扩展功能。
SSSD 如何处理配置文件
SSSD 按以下顺序读取配置文件:
-
主
/etc/sssd/sssd.conf
文件 -
/etc/sssd/conf.d/
中的其他*.conf
文件,按字母顺序排列
如果同一参数出现在多个配置文件中,SSSD 将使用最后一个读取的参数。
SSSD 不读取 conf.d
目录中的隐藏文件(以 .
开头的文件)。
2.4. SSSD 的身份和验证供应商
您可以将 SSSD 客户端连接到外部身份和身份验证供应商,如 LDAP 目录、身份管理 (IdM)、Active Directory(AD)域或 Kerberos 域。然后,SSSD 客户端使用 SSSD 供应商访问身份和身份验证远程服务。您可以将 SSSD 配置为使用不同的身份和身份验证供应商或它们的组合。
身份识别和身份验证提供程序作为 SSSD 域
身份和身份验证提供程序在 SSSD 配置文件 /etc/sssd/sssd.conf
中配置为 domains(域)。提供程序在文件的 [domain/name of the domain]
或 [domain/default]
部分中列出。
可将单个域配置为以下供应商之一:
一个身份供应商,它提供用户信息,如 UID 和 GID。
-
使用
/etc/sssd/sssd.conf
文件的[domain/name of the domain]
部分中的id_provider
选项将域指定为 身份提供程序。
-
使用
一个身份验证供应商,用于处理身份验证请求。
-
使用
/etc/sssd/sssd.conf
的[domain/name of the domain]
部分中的auth_provider
选项将域指定为 身份验证提供程序。
-
使用
访问控制提供程序,负责处理授权请求。
-
使用
/etc/sssd/sssd.conf
的[domain/name of the domain ]
部分中的access_provider
选项将域指定为 访问控制提供程序。默认情况下,选项设置为permit
,这将始终允许所有访问。详情请查看 sssd.conf(5)man page。
-
使用
组合这些供应商,例如,所有对应的操作都是在单一服务器中执行的。
-
在本例中,
id_provider
、auth_provider
和access_provider
选项都列在/etc/sssd/sssd.conf
的相同的[domain/name of the domain]
或[domain/default]
部分。
-
在本例中,
您可以为 SSSD 配置多个域。您必须至少配置一个域,否则 SSSD 不会启动。
代理供应商
代理供应商充当 SSSD 和 SSSD 资源之间的中间中继。使用代理供应商时,SSSD 会连接到代理服务,代理会加载指定的库。
您可以将 SSSD 配置为使用代理供应商启用:
- 其他验证方法,如指纹扫描仪
- 传统系统,如 NIS
-
在
/etc/passwd
文件中定义的本地系统帐户作为身份提供程序和远程身份验证提供程序,如 Kerberos
身份供应商可以和认证服务商组合使用
您可以将 SSSD 配置为使用以下身份和验证供应商的组合。
表 2.1. 身份供应商可以和认证服务商组合使用
第 3 章 配置 SSSD 以使用 LDAP 并需要 TLS 身份验证
系统安全服务守护进程(SSSD)是一个在 Red Hat Enterprise Linux 主机上管理身份数据检索和身份验证的守护进程。系统管理员可以将主机配置为使用独立 LDAP 服务器作为用户帐户数据库。管理员还可以指定与 LDAP 服务器的连接必须使用 TLS 证书加密的要求。
用于强制 TLS ldap_id_use_start_tls
的 SSSD 配置选项,默认为 false
。当在没有 TLS 进行身份查找的情况下使用 ldap://
时,可能会导致攻击向量的风险,即一个中间人(MITM)攻击,它允许您通过更改用户来模拟用户,例如:在 LDAP 搜索中返回的对象的 UID 或 GID。
确保您的设置在可信环境中运行,并决定是否可以安全地对 id_provider = ldap
使用未加密的通信。注意 id_provider = ad
和 id_provider = ipa
不受影响,因为它们使用 SASL 和 GSSAPI 保护的加密连接。
如果无法使用未加密的通信,您应该通过在 /etc/sssd/sssd.conf
文件中将 ldap_id_use_start_tls
选项设置为 true
来强制实施 TLS。
3.1. 使用 SSSD 的 OpenLDAP 客户端以加密的方式从 LDAP 检索数据
LDAP 对象的验证方法可以是 Kerberos 密码,也可以是 LDAP 密码。请注意,本章没有涉及 LDAP 对象的验证和授权问题。
使用 LDAP 配置 SSSD 是一个复杂的流程,需要对 SSSD 和 LDAP 有非常专业的知识。考虑改为使用集成和自动化解决方案,如 Active Directory 或 Red Hat Identity Management (IdM)。有关 IdM 的详情,请参阅规划身份管理。
3.2. 配置 SSSD 以使用 LDAP 并需要 TLS 身份验证
完成这个步骤,将 Red Hat Enterprise Linux (RHEL) 系统配置为 OpenLDAP 客户端。
使用以下客户端配置:
- RHEL 系统验证存储在 OpenLDAP 用户帐户数据库中的用户。
- RHEL 系统使用系统安全服务守护进程 (SSSD) 服务检索用户数据。
- RHEL 系统通过 TLS 加密的连接与 OpenLDAP 服务器通信。
您还可以使用此流程将 RHEL 系统配置为 Red Hat Directory Server 的客户端。
先决条件
- OpenLDAP 服务器安装并配置了用户信息。
- 您在要配置为 LDAP 客户端的主机上具有 root 权限。
-
在您要配置为 LDAP 客户端的主机上,已创建并配置了
/etc/sssd/sssd.conf
文件,以将ldap
指定为autofs_provider
和id_provider
。 -
您有来自发布 OpenLDAP 服务器的证书颁发机构的 root CA 签名证书链的 PEM 格式副本,存储在名为
core-dirsrv.ca.pem
的本地文件中。
流程
安装必要的软件包:
# dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir
将身份验证供应商切换到
sssd
:# authselect select sssd with-mkhomedir
将包含 root CA 签名证书链的
core-dirsrv.ca.pem
文件从颁发 OpenLDAP 服务器的 SSL/TLS 证书的证书颁发机构链复制到/etc/openldap/certs
文件夹。# cp core-dirsrv.ca.pem /etc/openldap/certs
将 LDAP 服务器的 URL 和后缀添加到
/etc/openldap/ldap.conf
文件中:URI ldap://ldap-server.example.com/ BASE dc=example,dc=com
在
/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
在
/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 …
在
/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 …
更改
/etc/sssd/sssd.conf
文件的权限:# chmod 600 /etc/sssd/sssd.conf
重启并启用 SSSD 服务和
oddjobd
守护进程:# systemctl restart sssd oddjobd # systemctl enable sssd oddjobd
(可选)如果您的 LDAP 服务器使用已弃用的 TLS 1.0 或 TLS 1.1 协议,请将客户端系统上系统范围的加密策略切换到 LEGACY 级别,以允许 RHEL 使用这些协议进行通信:
# update-crypto-policies --set LEGACY
如需了解更多详细信息,请参阅红帽客户门户网站上的知识库文章 RHEL 8 中的强加密默认值和弱加密算法的弃用 以及
update-crypto-policies(8)
手册页。
验证步骤
验证您可以使用
id
命令和指定 LDAP 用户从 LDAP 服务器检索用户数据:# id ldap_user uid=17388(ldap_user) gid=45367(sysadmins) groups=45367(sysadmins),25395(engineers),10(wheel),1202200000(admins)
系统管理员现在可以使用 id
命令从 LDAP 查询用户。该命令返回一个正确的用户 ID 和组群成员。
第 4 章 其他身份和身份验证供应商配置
系统安全服务后台程序 (SSSD) 是一种用于访问远程目录和身份验证机制的系统服务。SSSD 的主要配置文件是 /etc/sssd/sssd.conf
。以下章节概述了如何通过修改 /etc/sssd/sssd.conf
文件来配置 SSSD 服务和域:
- 调整 SSSD 如何解析并打印完整用户名,以启用离线身份验证。
- 配置 DNS 服务发现、简单访问提供程序规则和 SSSD 以应用 LDAP 访问过滤器。
4.1. 调整 SSSD 如何解释完整用户名
SSSD 将完整的用户名字符串解析到用户名和域组件中。默认情况下,SSSD 根据 Python 语法中的以下正则表达式解释 user_name@domain_name
格式的完整用户名:
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
对于 Identity Management 和 Active Directory 提供程序,默认的用户名格式为 user_name@domain_name
或 NetBIOS_name\user_name
。
您可以通过在 /etc/sssd/sssd.conf
文件中添加 re_expression
选项并定义自定义正则表达式来调整 SSSD 如何解释完整的用户名。
-
要全局定义正则表达式,请将正则表达式添加到
sssd.conf
文件的[sssd]
部分,如在全局范围内定义正则表达式所示。 -
要为特定的域定义正则表达式,请将正则表达式添加到
sssd.conf
文件的相应的域部分(如[domain/LDAP]
)中,如 为特定域定义正则表达式 示例中所示。
先决条件
-
root
访问权限
流程
-
打开
/etc/sssd/sssd.conf
文件: 使用
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>[^\\]+$)
如需了解更多详细信息,请参阅 sssd.conf(5)
手册页中的 SPECIAL SECTIONS
和 DOMAIN SECTIONS
部分的对 re_expression
的描述。
4.2. 调整 SSSD 如何打印完整用户名
如果在 /etc/sssd/sssd.conf
文件中启用了 use_fully_qualified_names
选项,SSSD 会默认根据以下扩展以 name@domain
格式打印完整的用户名:
%1$s@%2$s
如果未为受信任的域设置 use_fully_qualified_names
,或者明确设置为 false
,则仅打印没有域部分的用户名。
您可以通过在 /etc/sssd/sssd.conf
文件中添加 full_name_format
选项并定义自定义扩展来调整 SSSD 显示完整用户名的格式。
先决条件
-
root
访问权限
流程
-
以
root
身份,打开/etc/sssd/sssd.conf
文件。 要为所有域定义全局扩展,请将
full_name_format
添加到sssd.conf
的[sssd]
部分:[sssd] [... file truncated ...] full_name_format = %1$s@%2$s
在这种情况下,用户名显示为
user@domain.test
。要定义特定域的用户名打印格式,请将
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
。
如需了解更多详细信息,请参阅 sssd.conf(5)
手册页中的 SPECIAL SECTIONS
和 DOMAIN SECTIONS
部分的 full_name_format
的说明。
SSSD 可在某些名称配置中剥离名称的域组件,这可能会导致身份验证错误。如果将 full_name_format
设置为非标准值,您会收到警告提示您将其更改为标准格式。
4.3. 启用离线验证
默认情况下,SSSD 不缓存用户凭证。在处理身份验证请求时,SSSD 始终联系身份提供程序。如果提供商不可用,用户身份验证会失败。
为确保在身份提供程序不可用时用户也可以被验证,在 /etc/sssd/sssd.conf
文件中将 cache_credentials
设置为 true
来启用凭证缓存。
SSSD 永远不会以纯文本形式缓存密码。它仅存储密码的哈希。
虽然凭证存储为 salted SHA-512 哈希,但如果攻击者管理访问缓存文件并使用括号强制攻击破坏密码,这可能会带来安全风险。访问缓存文件需要特权访问权限,这是 RHEL 中的默认设置。
先决条件
-
root
访问权限
流程
-
打开
/etc/sssd/sssd.conf
文件: 在 domain 部分中,添加
cache_credentials = true
设置:[domain/your-domain-name] cache_credentials = true
可选,但建议:在身份提供程序不可用时为 SSSD 允许离线验证的时间限制:
配置 PAM 服务以使用 SSSD。
如需了解更多详细信息,请参阅使用 authselect 配置用户身份验证。
使用
offline_credentials_expiration
选项来指定时间限制。请注意,限制以天数为单位。
例如,要指定用户在上一次成功登录后 3 天可以离线验证,请使用:
[pam] offline_credentials_expiration = 3
其它资源
-
sssd.conf(5)
手册页
4.4. 配置 DNS 服务发现
DNS 服务发现使应用程序能够检查给定域中特定类型的特定服务的 SRV 记录,然后返回与所需类型匹配的服务器。如果在 /etc/sssd/sssd.conf
文件中未明确定义身份或身份验证服务器,SSSD 可以使用 DNS 服务发现动态发现服务器。
例如,如果 sssd.conf
包含 id_provider = ldap
设置,但是 ldap_uri
选项没有指定任何主机名或 IP 地址,SSSD 会使用 DNS 服务发现来动态发现服务器。
SSSD 无法动态发现备份服务器,只有主服务器。
先决条件
-
root
访问权限
流程
-
打开
/etc/sssd/sssd.conf
文件: 将主服务器值设置为
_srv_
。对于 LDAP 供应商,使用
ldap_uri
选项设置主服务器:[domain/your-domain-name] id_provider = ldap ldap_uri = _srv_
设置服务类型,在密码更改供应商中启用服务发现:
[domain/your-domain-name] id_provider = ldap ldap_uri = _srv_ chpass_provider = ldap ldap_chpass_dns_service_name = ldap
-
可选: 默认情况下,服务发现使用系统主机名的域部分作为域名。要使用不同的 DNS 域,请使用
dns_discovery_domain
选项指定域名。 -
可选: 默认情况下,会扫描 LDAP 服务类型的服务发现扫描。要使用不同的服务类型,请使用
ldap_dns_service_name
选项指定类型。 -
可选: 默认情况下,SSSD 会尝试查找 IPv4 地址。如果尝试失败,SSSD 会尝试查找 IPv6 地址。要自定义此行为,请使用
lookup_family_order
选项。 对于您要使用服务发现的每个服务,在 DNS 服务器中添加 DNS 记录:
_service._protocol._domain TTL priority weight port host_name
其它资源
- RFC 2782,DNS 服务发现
-
sssd.conf(5)
手册页
4.5. 配置简单的访问提供程序规则
simple
访问提供程序会基于用户名或组允许或拒绝访问。它可让您限制对特定机器的访问。
例如,您可以使用 simple
访问供应商限制对特定用户或组的访问。即使他们针对配置的身份验证提供程序成功进行身份验证,也不允许其他用户或组登录。
先决条件
-
root
访问权限
流程
-
打开
/etc/sssd/sssd.conf
文件: 将
access_provider
选项设置为simple
:[domain/your-domain-name] access_provider = simple
为用户定义访问控制规则。
-
要允许访问用户,请使用
simple_allow_users
选项。 若要拒绝用户访问,可使用
simple_deny_users
选项。重要如果您拒绝对特定用户的访问,则会自动允许对所有其他用户的访问。因此,允许访问特定用户通常被认为比拒绝对特定用户的访问更安全。
-
要允许访问用户,请使用
定义组的访问控制规则。选择以下任意一项:
-
若要允许访问组,可使用
simple_allow_groups
选项。 若要拒绝对组的访问,可使用
simple_deny_groups
选项。重要如果您拒绝访问特定组,则会自动允许访问其他任何组。因此,允许访问特定组通常被认为比拒绝对特定组的访问更安全。
例 4.3. 允许访问特定用户和组
以下示例允许访问 user1、user2 和 group1 的成员,同时拒绝对所有其他用户的访问:
[domain/your-domain-name] access_provider = simple simple_allow_users = user1, user2 simple_allow_groups = group1
-
若要允许访问组,可使用
将拒绝列表保留为空可能会导致允许任何人访问。
其它资源
-
sssd-simple5
man page
4.6. 配置 SSSD 以应用 LDAP 访问过滤器
如果在 /etc/sssd/sssd.conf
中设置 access_provider
选项,SSSD 会使用指定的访问提供程序来评估哪些用户被授予系统访问权限。如果您正在使用的访问提供程序是 LDAP 供应商类型的扩展,您也可以指定用户必须匹配的 LDAP 访问控制过滤器,才能允许访问该系统。
例如,当使用 Active Directory (AD) 服务器作为访问提供程序时,您可以将 Linux 系统的访问权限限制为指定的 AD 用户。与指定过滤器不匹配的所有其他用户的访问都被拒绝。
访问过滤器仅应用于 LDAP 用户条目。因此,在嵌套组上使用这种类型的访问控制可能无法正常工作。要在嵌套的组中应用访问控制,请参阅配置 simple
访问提供程序规则。
在使用脱机缓存时,SSSD 会检查用户最近的在线登录尝试是否成功。在最近一次在线登录期间成功登录的用户仍将能够脱机登录,即使他们与访问过滤器不匹配。
先决条件
-
root
访问权限
流程
-
打开
/etc/sssd/sssd.conf
文件: 在
[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=*))
-
对于 LDAP 访问提供程序,请使用
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
其它资源
-
sssd-ldap(5)
手册页
第 5 章 SSSD 客户端侧的视图
SSSD 提供 sss_override
工具,允许您创建一个本地视图,显示特定于本地机器的 POSIX 用户或组属性的值。您可以为所有 id_provider
值配置覆盖,但 ipa
除外。
如果您使用 ipa
提供程序,请在 IPA 中集中定义 ID 视图。如需更多信息,请参阅使用 ID 视图覆盖 IdM 客户端 中的用户属性值。
有关 SSSD 性能的潜在负面影响的信息,请参阅 SSSD 性能 上的 ID 视图的负面影响。
5.1. 覆盖 LDAP username 属性
作为管理员,您可以将现有主机配置为使用 LDAP 中的帐户。但是,LDAP 中用户(名称、UID、GID、主目录、shell)的值与本地系统中的值不同。您可以按照以下步骤定义二级 username
来覆盖 LDAP username
属性。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
显示用户的当前信息:
# id username
使用用户名替换 username。
添加二级
username
:# sss_override user-add username -n secondary-username
使用用户的名称替换 username,并使用新
username
替换 secondary-username。使用
sss_override user-add
命令创建第一次覆盖后,重启 SSSD 以使更改生效:# systemctl restart sssd
验证步骤
验证是否添加了新的
username
:# id secondary-username
可选。显示用户的覆盖:
# sss_override user-show user-name user@ldap.example.com:secondary-username::::::
例 5.1. 定义二级用户名
为用户 sjones 添加一个二级
username
sarah。显示用户 sjones 的当前信息:
# id sjones uid=1001(sjones) gid=6003 groups=6003,10(wheel)
添加二级
username
:# sss_override user-add sjones -n sarah
验证新
username
已添加并正确覆盖用户显示:# id sarah uid=1001(sjones) gid=6003(sjones) groups=6003(sjones),10(wheel) # sss_override user-show sjones user@ldap.example.com:sarah::::::
其它资源
-
sss_override
man page
5.2. 覆盖 LDAP UID 属性
作为管理员,您可以将现有主机配置为使用 LDAP 中的帐户。但是,LDAP 中用户(名称、UID、GID、主目录、shell)的值与本地系统中的值不同。您可以按照以下步骤定义不同的 UID 来覆盖 LDAP UID 属性。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
显示用户当前的 UID:
# id -u user-name
使用用户名称替换 user-name。
覆盖用户帐户的 UID:
# sss_override user-add user-name -u new-UID
使用用户名替换 user-name,再将 new-UID 替换为新的 UID 号。
使内存缓存过期:
# sss_cache --users
使用
sss_override user-add
命令创建第一次覆盖后,重启 SSSD 以使更改生效:# systemctl restart sssd
验证步骤
验证新 UID 是否已应用:
# id -u user-name
可选。显示用户的覆盖:
# sss_override user-show user-name user@ldap.example.com::new-UID:::::
例 5.2. 覆盖用户的 UID
使用 UID 6666 覆盖用户 sarah 的 UID:
显示 sarah 用户的当前 UID:
# id -u sarah 1001
使用 UID 6666 覆盖用户 sarah 的帐户的 UID:
# sss_override user-add sarah -u 6666
手动使内存缓存过期:
# sss_cache --users
重启 SSSD 以使更改生效:
# systemctl restart sssd
验证是否应用了新的 UID,并正确覆盖用户显示:
# id sarah 6666 # sss_override user-show sarah user@ldap.example.com::6666:::::
其它资源
-
sss_override
man page
5.3. 覆盖 LDAP GID 属性
作为管理员,您可以将现有主机配置为使用 LDAP 中的帐户。但是,LDAP 中用户(名称、UID、GID、主目录、shell)的值与本地系统中的值不同。您可以按照以下步骤定义不同的 GID 来覆盖 LDAP GID 属性。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
显示用户当前的 GID:
# id -g user-name
使用用户名称替换 user-name。
覆盖用户帐户的 GID:
# sss_override user-add user-name -g new-GID
使用用户名替换 user-name,并使用新的 GID 号替换 new-GID。
使内存缓存过期:
# sss_cache --users
使用
sss_override user-add
命令创建第一次覆盖后,重启 SSSD 以使更改生效:# systemctl restart sssd
验证步骤
验证是否应用了新的 GID:
# id -g user-name
可选。显示用户的覆盖:
# sss_override user-show user-name user@ldap.example.com:::6666::::
例 5.3. 覆盖用户的 GID
使用 GID 6666 覆盖用户 sarah 的 GID:
显示用户 sarah 的当前 GID:
# id -g sarah 6003
使用 GID 6666 覆盖用户 sarah 的帐户的 GID:
# sss_override user-add sarah -g 6666
手动使内存缓存过期:
# sss_cache --users
如果这是您的第一次覆盖,重启 SSSD 以使更改生效:
# systemctl restart sssd
验证是否应用了新的 GID 并正确覆盖用户显示:
# id -g sarah 6666 # sss_override user-show sarah user@ldap.example.com::6666:::::
其它资源
-
sss_override
man page
5.4. 覆盖 LDAP 主目录属性
作为管理员,您可以将现有主机配置为使用 LDAP 中的帐户。但是,LDAP 中用户(名称、UID、GID、主目录、shell)的值与本地系统中的值不同。您可以按照以下步骤定义不同的主目录来覆盖 LDAP 主目录属性。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
显示用户的当前主目录:
# getent passwd user-name user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash
使用用户名称替换 user-name。
覆盖用户的主目录:
# sss_override user-add user-name -h new-home-directory
使用用户名替换 user-name,并使用新的主目录替换 new-home-directory。
重启 SSSD 以使更改生效:
# systemctl restart sssd
验证步骤
验证是否定义了新主目录:
# getent passwd user-name user-name:x:XXXX:XXXX::/home/new-home-directory:/bin/bash
可选。显示用户的覆盖:
# sss_override user-show user-name user@ldap.example.com:::::::new-home-directory::
例 5.4. 覆盖用户的主目录
使用 admin 覆盖 sarah 用户的主目录:
显示 sarah 用户的当前主目录:
# getent passwd sarah sarah:x:1001:6003::sarah:/bin/bash
使用新主目录 admin 覆盖 sarah 用户的主目录:
# sss_override user-add sarah -h admin
重启 SSSD 以使更改生效:
# systemctl restart sssd
验证新主目录是否已定义,并正确覆盖用户显示:
# getent passwd sarah sarah:x:1001:6003::admin:/bin/bash # sss_override user-show user-name user@ldap.example.com:::::::admin::
其它资源
-
sss_override
man page
5.5. 覆盖 LDAP shell 属性
作为管理员,您可以将现有主机配置为使用 LDAP 中的帐户。但是,LDAP 中用户(名称、UID、GID、主目录、shell)的值与本地系统中的值不同。您可以通过按照以下步骤定义不同的 shell 来覆盖 LDAP shell 属性。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
显示用户当前的 shell:
# getent passwd user-name user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash
使用用户名称替换 user-name。
覆盖用户的 shell:
# sss_override user-add user-name -s new-shell
使用用户名替换 user-name,并使用新 shell 替换 new-shell。
重启 SSSD 以使更改生效:
# systemctl restart sssd
验证步骤
验证是否定义了新 shell:
# getent passwd user-name user-name:x:XXXX:XXXX::/home/home-directory:new-shell
可选。显示用户的覆盖:
# sss_override user-show user-name user@ldap.example.com::::::new-shell:
例 5.5. 覆盖用户的 shell
将用户 sarah 的 shell 从
/bin/bash
改为sbin/nologin
:显示用户 sarah 的当前 shell:
# getent passwd sarah sarah:x:1001:6003::sarah:/bin/bash
使用新的
/sbin/nologin
shell 覆盖用户 sarah 的 shell:# sss_override user-add sarah -s /sbin/nologin
重启 SSSD 以使更改生效:
# systemctl restart sssd
验证新 shell 是否已定义并正确覆盖用户显示:
# getent passwd sarah sarah:x:1001:6003::sarah:/sbin/nologin # sss_override user-show user-name user@ldap.example.com::::::/sbin/nologin:
其它资源
-
sss_override
man page
5.6. 列出主机上的覆盖
作为管理员,您可以列出主机上的所有用户和组覆盖,以验证是否已覆盖正确的属性。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
列出所有用户覆盖:
# sss_override user-find user1@ldap.example.com::8000::::/bin/zsh: user2@ldap.example.com::8001::::/bin/bash: ...
列出所有组覆盖:
# sss_override group-find group1@ldap.example.com::7000 group2@ldap.example.com::7001 ...
5.7. 删除本地覆盖
如果要删除全局 LDAP 目录中定义的本地覆盖,请使用以下步骤:
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
要删除用户帐户的覆盖,请使用:
# sss_override user-del user-name
使用用户名称替换 user-name。更改会立即生效。
要为组群删除覆盖,请使用:
# sss_override group-del group-name
使用
sss_override user-del
或sss_override group-del
命令删除第一次覆盖后,重启 SSSD 以使更改生效:# systemctl restart sssd
当您为用户或组群删除覆盖时,此对象的所有覆盖都会被删除。
5.8. 导出和导入本地视图
您的本地覆盖保存在本地 SSSD 缓存中。您可以将用户和组覆盖从此缓存导出到文件,以创建备份。这样可确保即使缓存被清除,您也可以稍后恢复配置。
先决条件
-
root
访问权限 -
已安装
sssd-tools
流程
要备份用户和组视图,请使用:
# sss_override user-export /var/lib/sss/backup/sssd_user_overrides.bak # sss_override group-export /var/lib/sss/backup/sssd_group_overrides.bak
要恢复用户和组视图,请使用:
# sss_override user-import /var/lib/sss/backup/sssd_user_overrides.bak # sss_override group-import /var/lib/sss/backup/sssd_group_overrides.bak
第 6 章 配置 RHEL 主机以使用 AD 作为身份验证提供程序
作为系统管理员,您可以在不将主机加入 AD 的情况下,使用 Active Directory (AD) 作为 Red Hat Enterprise Linux (RHEL) 主机的身份验证供应商。
例如在以下情况下可以实现:
- 您不想向 AD 管理员授予对启用和禁用主机的控制权。
- 主机(可以是一个公司 PC)只表示被您公司中的某一用户使用。
仅在很少情况下使用此方法。
考虑将系统完全加入 AD 或 Red Hat Identity Management (IdM)。将 RHEL 主机加入到域中可方便管理设置。如果您关注与将客户端直接加入 AD 中的客户端访问许可证,请考虑利用与 AD 信任协议中的 IdM 服务器。如需有关 IdM-AD 信任的更多信息,请参阅 规划 IdM 和 AD 间的跨林信任,并在 IdM 和 AD 间安装信任。
此流程可让名为 AD_user 的用户使用 example.com 域中的活动目录(AD)用户数据库中设置的密码登录到 rhel_host 系统。在这个示例中,EXAMPLE.COM Kerberos realm 对应于 example.com 域。
先决条件
- 您有访问 rhel_host 的 root 权限。
- AD_user 用户帐户存在于 example.com 域中。
- Kerberos realm 是 EXAMPLE.COM。
-
rhel_host 尚未使用
realm join
命令加入到 AD。
流程
在本地创建 AD_user 用户帐户而不为其分配密码:
# useradd AD_user
打开
/etc/nsswitch.conf
文件进行编辑,并确保该文件包含以下行:passwd: sss files systemd group: sss files systemd shadow: files sss
打开
/etc/krb5.conf
文件进行编辑,并确保该文件包含以下部分和项目:# To opt out of the system crypto-policies configuration of krb5, remove the # symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated. includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt spake_preauth_groups = edwards25519 default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} [realms] EXAMPLE.COM = { kdc = ad.example.com admin_server = ad.example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
创建
/etc/sssd/sssd.conf
文件,并将以下部分和行插入到该文件中:[sssd] services = nss, pam domains = EXAMPLE.COM [domain/EXAMPLE.COM] id_provider = files auth_provider = krb5 krb5_realm = EXAMPLE.COM krb5_server = ad.example.com
更改
/etc/sssd/sssd.conf
文件的权限:# chmod 600 /etc/sssd/sssd.conf
启动安全性系统服务守护进程(SSSD):
# systemctl start sssd
启用 SSSD:
# systemctl enable sssd
打开
/etc/pam.d/system-auth
文件,修改该文件使其包含以下部分和行:# Generated by authselect on Wed May 8 08:55:04 2019 # 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 account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
将
/etc/pam.d/system-auth
文件的内容复制到/etc/pam.d/password-auth
文件中。输入 yes 来确认覆盖文件的当前内容:# cp /etc/pam.d/system-auth /etc/pam.d/password-auth cp: overwrite '/etc/pam.d/password-auth'? yes
验证步骤
为 AD_user 请求 Kerberos 票据 (TGT)。根据请求输入 AD_user 密码:
# kinit AD_user Password for AD_user@EXAMPLE.COM:
显示获得的 TGT:
# klist Ticket cache: KEYRING:persistent:0:0 Default principal: AD_user@EXAMPLE.COM Valid starting Expires Service principal 11/02/20 04:16:38 11/02/20 14:16:38 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 18/02/20 04:16:34
AD_user 已使用 EXAMPLE.COM Kerberos 域中的凭据成功登录到 rhel_host。
第 7 章 使用 SSSD 报告主机的用户访问权限
安全系统服务守护进程 (SSSD) 跟踪用户可以或无法访问哪些客户端。本章论述了使用 sssctl
工具创建访问控制报告并显示用户数据。
先决条件
- SSSD 软件包安装在网络环境中
7.1. sssctl 命令
sssctl
是一个命令行工具,提供获取安全系统服务守护进程 (SSSD) 状态信息的统一方法。
您可以使用 sssctl
工具收集有关的信息:
- 域状态
- 客户端用户验证
- 特定域的客户端访问
- 有关缓存内容的信息
使用 sssctl
工具,您可以:
- 管理 SSSD 缓存
- 管理日志
- 检查配置文件
sssctl
工具取代了 sss_cache
和 sss_debuglevel
工具。
其它资源
-
sssctl --help
7.2. 使用 sssctl 生成访问控制报告
您可以列出应用到您要运行报告的机器的访问控制规则,因为 SSSD 控制哪些用户可以登录到客户端。
访问报告不准确,因为这个工具不会跟踪由密钥发布中心(KDC)锁定的用户。
先决条件
- 您必须使用管理员权限登录
-
ssctl
工具已在 RHEL 7 和 RHEL 8 系统上提供。
流程
要为
idm.example.com
域生成报告,请输入:[root@client1 ~]# sssctl access-report idm.example.com 1 rule cached Rule name: example.user Member users: example.user Member services: sshd
7.3. 使用 sssctl 显示用户授权详情
sssctl user-checks
命令有助于调试使用系统安全服务守护进程 (SSSD) 进行用户查找、身份验证和授权的应用中的问题。
sssctl user-checks [USER_NAME]
命令显示通过 Name Service Switch (NSS) 获取的用户数据,以及 D-Bus 接口的 InfoPipe responseer。显示的数据显示用户是否被授权使用 system-auth
可插拔验证模块 (PAM) 服务登录。
命令有两个选项:
-
-a
用于 PAM 操作 -
-s
用于 PAM 服务
如果没有定义 -a
和 -s
选项,sssctl
会使用默认选项:-a acct -s system-auth
。
先决条件
- 您必须使用管理员权限登录
-
ssctl
工具已在 RHEL 7 和 RHEL 8 系统上提供。
流程
要显示特定用户的用户数据,请输入:
[root@client1 ~]# sssctl user-checks -a acct -s sshd example.user user: example.user action: acct service: sshd ....
其它资源
-
sssctl user-checks --help
第 8 章 使用 SSSD 查询域信息
安全系统服务守护进程 (SSSD) 可以列出身份管理 (IdM) 中的域,以及 Active Directory 中的域,这些域通过跨林信任连接到 IdM。
8.1. 使用 sssctl 列出域
您可以使用 sssctl domain-list
命令来调试域拓扑的问题。
这个状态可能立即不可用。如果该域不可见,请重复该命令。
先决条件
- 您必须使用管理员权限登录
-
ssctl
工具已在 RHEL 7 和 RHEL 8 系统上提供。
流程
要显示 sssctl 命令的帮助信息,请输入:
[root@client1 ~]# sssctl --help ....
- 要显示可用域列表,请输入:
[root@client1 ~]# sssctl domain-list
implicit_files
idm.example.com
ad.example.com
sub1.ad.example.com
该列表包含 Active Directory 和 Identity Management 间的跨林信任域。
8.2. 使用 sssctl 验证域状态
您可以使用 sssctl domain-status
命令来调试域拓扑的问题。
这个状态可能立即不可用。如果该域不可见,请重复该命令。
先决条件
- 您必须使用管理员权限登录
-
ssctl
工具已在 RHEL 7 和 RHEL 8 系统上提供。
流程
要显示 sssctl 命令的帮助信息,请输入:
[root@client1 ~]# sssctl --help
要显示特定域的用户数据,请输入:
[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
域 idm.example.com
在线,并在可应用命令的客户端可见。
如果域不可用,则结果为:
[root@client1 ~]# sssctl domain-status ad.example.com
Unable to get online status
第 9 章 使用 SSSD 限制 PAM 服务的域
可插拔验证模块 (PAM) 是身份验证和授权的通用框架。Red Hat Enterprise Linux 中的大多数系统应用程序依赖于底层 PAM 配置进行身份验证和授权。
系统安全服务守护进程 (SSSD) 可让您限制 PAM 服务可以访问哪些域。SSSD 根据运行特定 PAM 服务的用户评估来自 PAM 服务的身份验证请求。这意味着,如果 PAM 服务用户可以访问 SSSD 域,PAM 服务也可以访问该域。
9.1. 关于 PAM
可插拔验证模块 (PAM) 提供集中式身份验证机制,系统应用可以使用此机制将身份验证中继到集中配置的框架。
PAM 可插拔,因为存在用于不同类型身份验证源(如 Kerberos、SSSD、NIS 或本地文件系统)的 PAM 模块。您可以对不同的身份验证源进行优先排序。
此模块化架构为管理员提供了很大的灵活性来为系统设置身份验证策略。PAM 对开发人员和管理员而言是有用的系统,原因如下:
- PAM 提供一种常见身份验证方案,可用于各种应用。
- PAM 为系统管理员提供了对身份验证的显著灵活性和控制力。
- PAM 提供单个全文档库,使开发人员无需创建自己的身份验证方案即可编写程序。
9.2. 域访问限制选项
以下选项可以用来限制对所选域的访问:
/etc/sssd/sssd.conf
中的pam_trusted_users
-
这个选项接受代表 SSSD 信任的 PAM 服务的数字 UID 或用户名列表。默认设置是
all
,这意味着所有服务用户都是受信任的,可以访问任何域。 /etc/sssd/sssd.conf
中的pam_public_domains
-
这个选项接受公共 SSSD 域列表。公共域是即使不可信 PAM 服务用户也可访问的域。选项也接受
all
和none
值。默认值为none
,这意味着没有域是公共域,不受信任的服务用户无法访问任何域。 - PAM 配置文件的
domains
此选项指定 PAM 服务可以对其进行身份验证的域列表。如果您在没有指定任何
domains
的情况下使用域,PAM 服务将无法对任何域进行身份验证,例如:auth required pam_sss.so domains=
如果 PAM 配置文件使用
domains
,则 PAM 服务能够在可信用户下运行时对所有域进行身份验证。/etc/sssd/sssd.conf
SSSD 配置文件中的domain
选项还指定 SSSD 尝试验证的域列表。请注意,PAM
配置文件中的 domain 选项无法扩展sssd.conf
中的域列表,它只能通过指定较短的列表来限制sssd.conf
域列表。因此,如果在 PAM 文件中指定了域,但没有在sssd.conf
中指定,则 PAM 服务无法对该域进行身份验证。
默认设置 pam_trusted_users = all
和 pam_public_domains = none
指定所有 PAM 服务用户都是可信并可访问任何域。将 domain
选项用于 PAM 配置文件会限制对域的访问。
使用 PAM 配置文件中的 domains
指定域,sssd.conf
包含 pam_public_domains
也需要在 pam_public_domains
中指定域。如果未包含所需域,pam_public_domains
选项将使 PAM 服务无法针对域进行身份验证,以防此服务在不受信任的用户下运行。
PAM 配置文件中定义的域限制仅适用于身份验证操作,不适用于用户查找。
其它资源
-
有关
pam_trusted_users
和pam_public_domains
选项的详情,请查看sssd.conf(5)
手册页。 -
有关 PAM 配置文件中使用的
domain
选项的更多详细信息,请参阅pam_sss(8)man
page。
9.3. 限制 PAM 服务的域
此流程演示了如何针对域限制 PAM 服务身份验证。
先决条件
- SSSD 已安装并运行。
流程
配置 SSSD 以访问所需的域。在
/etc/sssd/sssd.conf
文件中的domain
选项中定义 SSSD 可对其进行身份验证的域:[sssd] domains = domain1, domain2, domain3
通过在 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
进行身份验证。
验证步骤
-
根据
domain1
进行验证。它必须成功。
第 10 章 将身份验证从 nslcd 迁移到 SSSD
10.1. 将 RHEL 客户端从 nslcd 迁移到 SSSD
由于 nss-pam-ldapd
软件包已从 RHEL 中删除,因此红帽建议迁移到 SSSD
及其 ldap
提供程序,它取代了 nslcd
服务的功能。以下流程描述了如何配置 SSSD
,以便在之前配置为使用 nss-pam-ldap
身份验证配置的客户端上来验证 LDAP 用户。
先决条件
- 您的 RHEL 客户端是 RHEL 8 或 RHEL 9。
-
您之前已将 RHEL 客户端配置为使用
nslcd
服务认证到 LDAP 目录服务器。 - LDAP 目录服务使用 RFC-2307 中定义的模式。
流程
备份当前的身份验证配置:
# authselect apply-changes -b --backup=ldap-configuration-backup
安装
SSSD
软件包:# yum install sssd-ldap sssd-ad sssd-client \ sssd-common sssd-common-pac \ sssd-krb5 sssd-krb5-common
停止并禁用
nslcd
和nscd
服务:# systemctl stop nslcd nscd # systemctl disable nslcd nscd
使用
SSSD
配置身份验证:# authselect select sssd with-mkhomedir --force
为
SSSD
配置文件设置必要的所有权和权限:# chown root:root /etc/sssd/sssd.conf # chmod 600 /etc/sssd/sssd.conf
-
打开
/etc/sssd/sssd.conf
文件进行编辑。 输入以下配置,将
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
服务。启用并启动
SSSD
服务:# systemctl enable sssd # systemctl start sssd
验证步骤
确保您可以检索有关 LDAP 用户的信息:
# id ldapuser uid=100424(ldapuser) gid=100424(ldapuser) groups=100424(ldapuser) # getent passwd ldapuser ldapuser:*: 100424: 100424:User, LDAP:/home/ldapuser:/bin/bash
确保您可以以 LDAP 用户身份登录:
# ssh -l ldapuser localhost ldapuser@localhost's password: Last login: Tue Dec 07 19:34:35 2021 from localhost -sh-4.2$
如果您需要使用 nslcd
和 nscd
恢复初始的 LDAP 配置,请使用以下命令:
# authselect backup-restore=ldap-configuration-backup # systemctl stop sssd && systemctl disable sssd # systemctl start nslcd nscd # systemctl enable nslcd nscd
10.2. sssd.conf
选项等同于 nslcd.conf
选项
为了帮助从 nslcd
迁移到 SSSD
,下表显示了 nslcd.conf
配置文件中的常用选项,以及它们在 sssd.conf
配置文件中等同的选项。
表 10.1. sssd.conf
选项等同于 nslcd.conf
选项
nslcd.conf 选项 | sssd.conf 选项 | 描述 |
---|---|---|
| 没有等同选项 |
运行守护进程的用户 ID。默认情况下,SSSD 以 |
| 没有等同选项 |
运行守护进程的组 ID。默认情况下,SSSD 以 |
|
|
LDAP 服务器的 URI,格式为: |
|
| 搜索基础的专有名称。 |
|
| 用于执行 LDAP 操作的默认绑定 DN |
|
| 默认绑定 DN 的身份验证令牌。目前只支持明文密码。 |
|
| 默认绑定 DN 的身份验证令牌。目前只支持明文密码。 |
|
| 指定在服务器提供的证书上执行哪些检查。 |
|
| 包含所有证书颁发机构证书的文件 |
|
| 在单独的文件中包含证书颁发机构证书的目录的路径。 |
|
| 可选的基本 DN、搜索范围和 LDAP 过滤器以限制 LDAP 搜索用户。 |
|
| 可选的基本 DN、搜索范围和 LDAP 过滤器以限制 LDAP 搜索组。 |
其它资源
-
nslcd.conf(5)
手册页 -
sssd-ldap(5)
手册页
第 11 章 在本地 SSSD 配置中消除拼写错误
您可以使用 sssctl config-check
命令测试主机上的 /etc/sssd/sssd.conf
文件是否包含任何拼写错误。
先决条件
- 以 root 身份登录。
-
sssd-tools
软件包已安装。
流程
输入
sssctl config-check
命令:# sssctl config-check Issues identified by validators: 1 [rule/allowed_domain_options]: Attribute 'ldap_search' is not allowed in section 'domain/example1'. Check for typos. Messages generated during configuration merging: 0 Used configuration snippet files: 0
打开
/etc/sssd/sssd.conf
文件并更正拼写错误。例如,如果您收到上一步中的出错信息,将 ldap_search 替换为 ldap_search_base:[...] [domain/example1] ldap_search_base = dc=example,dc=com [...]
- 保存该文件。
重启 SSSD:
# systemctl restart sssd
验证步骤
输入
sssctl config-check
命令:# sssctl config-check Issues identified by validators: 0 Messages generated during configuration merging: 0 Used configuration snippet files: 0
/etc/sssd/sssd.conf
文件现在没有拼写错误。
第 12 章 IdM 中 SSSD 身份验证故障排除
在 Identity Management(IdM)环境中的身份验证涉及许多组件:
在 IdM 客户端中:
- SSSD 服务。
- Name Services Switch (NSS)。
- 可插拔验证模块 (PAM)。
在 IdM 服务器上:
- SSSD 服务。
- IdM 目录服务器。
- IdM Kerberos 密钥分发中心 (KDC)。
如果您要以 Active Directory (AD) 用户进行身份验证:
- AD 域控制器上的目录服务器。
- AD 域控制器上的 Kerberos 服务器。
要验证用户,您必须使用 SSSD 服务执行以下功能:
- 从身份验证服务器检索用户信息。
- 提示用户输入其凭据,将这些凭据传递到身份验证服务器,然后处理结果。
以下小节讨论 SSSD 服务和存储用户信息的服务器之间的信息流,以便您可以排除环境中身份验证尝试失败的问题:
12.1. 使用 SSSD 获取 IdM 用户信息时的数据流
下图使用 getent passwd <idm_user_name>
命令在请求 IdM 用户信息的过程中简化 IdM 客户端和 IdM 服务器之间的信息流。
-
getent
命令会触发来自libc
库的getpwnam
调用。 -
libc
库引用/etc/nsswitch.conf
配置文件来检查哪个服务负责提供用户信息,并发现SSSD
服务的条目。 -
libc
库打开ss_sss
模块。 -
nss_sss 模块检查内存映射缓存以获取用户信息。如果缓存中存在数据,则
ss_sss
模块会返回它。 -
如果用户信息不在内存映射缓存中,则会将请求传递给 SSSD
sssd_nss
响应程序进程。 -
SSSD 服务检查其缓存。如果缓存中存在数据并有效,
sssd_nss
响应程序会从缓存中读取数据并将其返回到应用。 -
如果缓存中没有数据或数据已过期,
sssd_nss
响应器将查询相应的后端进程并等待回复。SSSD 服务在 IdM 环境中使用 IPA 后端,通过sssd.conf
配置文件中的id_provider=ipa
启用。 -
sssd_be
后端进程连接到 IdM 服务器,并从 IdM LDAP 目录服务器请求信息。 - IdM 服务器上的 SSSD 后端响应 IdM 客户端上的 SSSD 后端进程。
- 客户端上的 SSSD 后端将生成的数据存储在 SSSD 缓存中,并提醒已更新缓存的响应程序进程。
-
sssd_nss
前端响应器进程从 SSSD 缓存检索信息。 -
sssd_nss
响应器将用户信息发送到ss_sss
响应者,以完成请求。 -
libc
库将用户信息返回到请求它的应用程序。
12.2. 使用 SSSD 获取 AD 用户信息时的数据流
如果您在 IdM 环境和 Active Directory (AD) 域之间建立了跨林信任,则在 IdM 客户端上检索 AD 用户信息时的信息流与检索 IdM 用户信息时的信息流非常相似,以及联系 AD 用户数据库的额外步骤。
下图是当用户使用 getent passwd <ad_user_name@ad.example.com>
命令请求 AD 用户信息时,信息流的简化。这个图并没有包括使用 SSSD 检索 IdM 用户信息时的数据流中讨论的内部详细信息。它侧重于 IdM 客户端上的 SSSD 服务、IdM 服务器上的 SSSD 服务和 AD 域控制器上的 LDAP 数据库之间的通信。
- IdM 客户端为 AD 用户信息查找其本地 SSSD 缓存。
-
如果 IdM 客户端没有用户信息,或者信息是 stale,客户端上的 SSSD 服务会联系 IdM 服务器上的
extdom_extop
插件来执行 LDAP 扩展操作并请求信息。 - IdM 服务器上的 SSSD 服务在其本地缓存中查找 AD 用户信息。
- 如果 IdM 服务器在其 SSSD 缓存中没有用户信息,或者其信息为过时,它将执行 LDAP 搜索,以从 AD 域控制器请求用户信息。
- IdM 服务器上的 SSSD 服务从 AD 域控制器接收 AD 用户信息,并将其存储在其缓存中。
-
extdom_extop
插件从 IdM 服务器上的 SSSD 服务接收信息,该服务完成 LDAP 扩展操作。 - IdM 客户端上的 SSSD 服务从 LDAP 扩展操作接收 AD 用户信息。
- IdM 客户端将 AD 用户信息存储在其 SSSD 缓存中,并将信息返回给请求它的应用程序。
12.3. 以 IdM 中的 SSSD 用户身份进行身份验证时的数据流
以 IdM 服务器或客户端中的用户身份进行身份验证涉及以下组件:
- 启动身份验证请求的服务,如 sshd 服务。
- 可插拔验证模块 (PAM) 库及其模块。
- SSSD 服务、其响应者和后端。
- 智能卡读取器(如果配置了智能卡验证)。
身份验证服务器:
- IdM 用户通过 IdM Kerberos 密钥分发中心 (KDC) 进行身份验证。
- Active Directory (AD) 用户通过 AD 域控制器 (DC) 进行身份验证。
下图是用户在尝试通过命令行上的 SSH 服务在本地登录主机期间需要进行身份验证时的简化信息流。
-
使用
ssh
命令尝试身份验证会触发libpam
库。 libpam
库引用/etc/pam.d/
目录中与请求身份验证尝试的服务对应的 PAM 文件。在本例中,libpam 库涉及通过本地主机上的 SSH 服务进行身份验证,libpam
库检查/etc/pam.d/system-auth
配置文件并发现 SSSD PAM 的pam_sss.so
条目:auth sufficient pam_sss.so
-
要确定哪些身份验证方法可用,
libpam
库会打开pam_sss
模块,并将SSS_PAM_PREAUTH
请求发送到 SSSD 服务的sssd_pam
PAM 响应者。 -
如果配置了智能卡验证,SSSD 服务会生成一个临时
p11_child
进程,以检查智能卡并从中检索证书。 -
如果为用户配置了智能卡验证,
sssd_pam
响应程序会尝试将智能卡中的证书与用户匹配。sssd_pam
响应器还搜索用户所属的组,因为组成员身份可能会影响访问控制。 -
sssd_pam
响应器将SSS_PAM_PREAUTH
请求发送到sssd_be
后端响应器,以查看服务器支持的身份验证方法,如密码或双因素身份验证。在 IdM 环境中,SSSD 服务使用 IPA 响应器,默认的身份验证方法是 Kerberos。在本例中,用户使用简单的 Kerberos 密码进行身份验证。 -
sssd_be
响应器生成一个临时krb5_child
进程。 -
krb5_child
进程联系 IdM 服务器上的 KDC,并检查可用的身份验证方法。 KDC 响应请求:
-
krb5_child
进程评估回复,并将结果发回到sssd_be
后端进程。 -
sssd_be
后端进程会收到结果。 -
sssd_pam
响应器会收到结果。 -
pam_sss
模块会收到结果。
-
-
如果为用户配置了密码身份验证,
pam_sss
模块将提示用户输入其密码。如果配置了智能卡验证,pam_sss
模块会提示用户输入其智能卡 PIN。 模块会发送带有用户名和密码的
SSS_PAM_AUTHENTICATE
请求,该请求经过以下操作:-
sssd_pam
响应器。 -
sssd_be
后端进程。
-
-
sssd_be
进程生成一个临时krb5_child
进程来联系 KDC。 -
krb5_child
进程尝试使用用户提供的用户名和密码从 KDC 检索 Kerberos Ticket Granting Ticket (TGT)。 -
krb5_child
进程接收身份验证尝试的结果。 krb5_child
进程:- 将 TGT 存储到凭据缓存中。
-
将身份验证结果返回到
sssd_be
后端进程。
身份验证结果从
sssd_be
进程传输到:-
sssd_pam
响应器。 -
pam_sss
模块。
-
-
pam_sss
模块使用用户 TGT 的位置设置环境变量,以便其他应用可以引用它。
12.4. 缩小身份验证问题的范围
要成功验证用户,您必须能够使用 SSSD 服务从存储用户信息的数据库检索用户信息。以下流程描述了测试身份验证流程的不同组件的步骤,以便您可以在用户无法登录时缩小身份验证问题的范围。
流程
验证 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
验证客户端可以通过 IP 地址联系用户数据库服务器。
[user@client ~]$ ping <IP_address_of_the_database_server>
如果此步骤失败,请检查您的网络和防火墙设置是否允许 IdM 客户端和服务器之间进行直接通信。请参阅使用和配置 firewalld。
验证客户端可以通过完全限定的主机名发现并联系 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>
如果使用这些选项,请验证您可以联系它们中列出的服务器。
-
验证客户端是否可以对 LDAP 服务器进行身份验证,并使用
ldapsearch
命令检索用户信息。如果您的 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>
如果您的 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>
如果您的 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 服务器。
由于 SSSD 服务使用 Kerberos 加密,因此请以无法登录的用户身份获得 Kerberos 票据。
如果您的 LDAP 服务器是 IdM 服务器:
[user@client ~]$ kinit <user_name>
如果 LDAP 服务器数据库是 AD 服务器:
[user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>
如果此步骤失败,请验证您的 Kerberos 服务器是否正常运行,所有服务器都已同步其时间,并且用户帐户未被锁定。
验证您是否可以通过命令行检索用户信息。
[user@client ~]$ getent passwd <user_name> [user@client ~]$ id <user_name>
如果这一步失败了,请验证客户端上的 SSSD 服务是否可以收到用户数据库的信息:
-
查看
/var/log/messages
日志文件中的错误。 - 在 SSSD 服务中启用详细的日志记录,收集调试日志,并查看提示性日志以了解问题的来源。
- (可选)创建一个红帽技术支持问题单,并提供您收集的故障排除信息。
-
查看
如果您被允许在主机上运行
sudo
,请使用sssctl
工具来验证用户是否被允许登录。[user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>
如果这一步失败了,请验证您的授权设置,如 PAM 配置、IdM HBAC 规则和 IdM RBAC 规则:
-
确保用户的 UID 等于或大于
UID_MIN
,它在/etc/login.defs
文件中定义。 -
查看
/var/log/secure
和/var/log/messages
日志文件中的授权错误。 - 在 SSSD 服务中启用详细的日志记录,收集调试日志,并查看提示性日志以了解问题的来源。
- (可选)创建一个红帽技术支持问题单,并提供您收集的故障排除信息。
-
确保用户的 UID 等于或大于
12.5. SSSD 日志文件和日志记录级别
每个 SSSD 服务都将日志记录到 /var/log/sssd/
目录中自己的日志文件中。对于 example.com
IdM 域中的 IdM 服务器,其日志文件可能类似这样:
[root@server ~]# ls -l /var/log/sssd/ total 620 -rw-------. 1 root root 0 Mar 29 09:21 krb5_child.log -rw-------. 1 root root 14324 Mar 29 09:50 ldap_child.log -rw-------. 1 root root 212870 Mar 29 09:50 sssd_example.com.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_ifp.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_implicit_files.log -rw-------. 1 root root 0 Mar 29 09:21 sssd.log -rw-------. 1 root root 219873 Mar 29 10:03 sssd_nss.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_pac.log -rw-------. 1 root root 13105 Mar 29 09:21 sssd_pam.log -rw-------. 1 root root 9390 Mar 29 09:21 sssd_ssh.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_sudo.log
12.5.1. SSSD 日志文件用途
krb5_child.log
- Kerberos 身份验证中涉及的短期帮助程序进程的日志文件。
ldap_child.log
- 与 LDAP 服务器通信的简短帮助程序进程的日志文件,涉及获取 Kerberos 票据。
sssd_<example.com>.log
对于
sssd.conf
文件中的每个域部分,SSSD 服务会将与 LDAP 服务器通信的信息记录到单独的日志文件中。例如,在名为example.com
的 IdM 域环境中,SSSD 服务将其信息记录到名为sssd_example.com.log
的文件中。如果主机直接与名为ad.example.com
的 AD 域集成,则信息将被记录到名为sssd_ad.example.com.log
的文件中。注意如果您有一个 IdM 环境以及与 AD 域的跨林信任,则有关 AD 域的信息仍会记录到 IdM 域的日志文件中。
类似地,如果主机直接集成到 AD 域,则任何子域的信息都会写入到主域的日志文件中。
selinux_child.log
- 用于检索和设置 SELinux 信息的短生命帮助器进程的日志文件。
sssd.log
- SSSD 监控并与其响应器和后端进程通信的日志文件。
sssd_ifp.log
- InfoPipe 响应器的日志文件,它提供了一个可通过系统总线访问的公共 D-Bus 接口。
sssd_nss.log
- 用于检索用户和组信息的 Name Services Switch (NSS) 响应器的日志文件。
sssd_pac.log
- Microsoft Privilege Attribute 证书 (PAC) 响应器的日志文件,从 AD Kerberos 票据收集 PAC,并从 PAC 中生成 AD 用户的信息,从而避免直接从 AD 请求它。
sssd_pam.log
- 可插拔验证模块 (PAM) 响应器的日志文件。
sssd_ssh.log
- SSH 响应器进程的日志文件。
12.5.2. SSSD 日志记录级别
设置一个 debug 级别后,也会启用它以下的所有 debug 级别。例如,把 debug 级别设置为 6 后,也会启用 debug 级别 0 到 5。
表 12.1. SSSD 日志记录级别
级别 | 描述 |
---|---|
0 | 致命故障。阻止 SSSD 服务启动或导致它终止的错误。这是 RHEL 8.3 及更早版本的默认调试日志级别。 |
1 | 关键故障。错误没有导致 SSSD 服务被终止,但至少有一个主要功能无法正常工作。 |
2 | 严重故障。这个错误声明特定请求或操作失败。这是 RHEL 8.4 及之后的版本的默认调试日志级别。 |
3 | 小故障。在级别 2 中捕获的操作失败的错误。 |
4 | 配置设置。 |
5 | 功能数据。 |
6 | 跟踪操作功能的消息。 |
7 | 跟踪内部控制功能的消息。 |
8 | 功能内部变量的内容。 |
9 | 极低级别跟踪信息。 |
12.6. 在 sssd.conf 文件中为 SSSD 启用详细日志记录
默认情况下,RHEL 8.4 及更新版本中的 SSSD 服务仅记录严重故障(调试级别 2),但不记录在对身份验证问题进行故障排除所需的详细级别。
要在 SSSD 服务重启过程中永久启用详细的日志记录,请在 /etc/sssd/sssd.conf
配置文件的每个部分添加 debug_level=<integer>
选项,其中 <integer>
值是一个 0 到 9 之间的数字。debug 级别 0 到 3 会记录大错误的日志,级别 8 和更高级别会提供大量详细的日志消息。级别 6 是调试身份验证问题的一个良好起点。
先决条件
-
您需要 root 密码来编辑
sssd.conf
配置文件并重新启动 SSSD 服务。
流程
-
在文本编辑器中打开
/etc/sssd/sssd.conf
文件。 将
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
-
保存并关闭
sssd.conf
文件。 重启 SSSD 服务以加载新的配置设置。
[root@server ~]# systemctl restart sssd
其它资源
12.7. 使用 sssctl 命令为 SSSD 启用详细的日志记录
默认情况下,RHEL 8.4 及更新版本中的 SSSD 服务仅记录严重故障(调试级别 2),但不记录在对身份验证问题进行故障排除所需的详细级别。
您可以在命令行中使用 sssctl debug-level <integer>
命令更改 SSSD 服务的 debug 级别,其中 <integer>
是 0 到 9 之间的一个数字。debug 级别 0 到 3 会记录大错误的日志,级别 8 和更高级别会提供大量详细的日志消息。级别 6 是调试身份验证问题的一个良好起点。
先决条件
-
您需要 root 密码来运行
sssctl
命令。
流程
使用 sssctl debug-level 命令将所选的调试级别设置为您所需的详细程度。
[root@server ~]# sssctl debug-level 6
其它资源
12.8. 从 SSSD 服务收集调试日志,对 IdM 服务器的身份验证问题进行故障排除
如果您在尝试以 IdM 用户身份对 IdM 服务器进行身份验证时遇到问题,请在服务器上的 SSSD 服务中启用详细的调试日志,并收集尝试检索用户信息的日志。
先决条件
-
您需要 root 密码来运行
sssctl
命令并重新启动 SSSD 服务。
流程
在 IdM 服务器上启用详细的 SSSD 调试日志。
[root@server ~]# sssctl debug-level 6
对于遇到身份验证问题的用户,在 SSSD 缓存中使相关的对象无效,这样使您不会绕过 LDAP 服务器来从缓存的 SSSD 中获取信息。
[root@server ~]# sssctl cache-expire -u idmuser
通过删除旧的 SSSD 日志来最大程度减少数据集的故障排除。
[root@server ~]# sssctl logs-remove
尝试切换至遇到身份验证问题的用户,同时在尝试前后收集时间戳。这些时间戳进一步缩小了数据集的范围。
[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
(可选)如果您不想继续收集详细的 SSSD 日志,请降低 debug 级别。
[root@server ~]# sssctl debug-level 2
查看 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
如果您无法确定导致身份验证问题的原因:
收集您最近生成的 SSSD 日志。
[root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar
创建一个红帽技术支持问题单并提供:
-
SSSD 日志:
sssd-logs-Mar29.tar
与日志对应的请求的控制台输出,包括时间戳和用户名:
[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
-
SSSD 日志:
12.9. 从 SSSD 服务收集调试日志,以对 IdM 客户端的身份验证问题进行故障排除
如果您在尝试以 IdM 用户身份向 IdM 客户端进行身份验证时遇到问题,请验证您可以检索 IdM 服务器上的用户信息。如果您无法在 IdM 服务器上检索用户信息,您将无法在 IdM 客户端(从 IdM 服务器检索信息)中检索它。
确认身份验证问题不源自 IdM 服务器后,从 IdM 服务器和 IdM 客户端收集 SSSD 调试日志。
先决条件
- 用户仅在 IdM 客户端而不是 IdM 服务器中存在身份验证问题。
-
您需要 root 密码来运行
sssctl
命令并重新启动 SSSD 服务。
流程
-
在客户端上: 在文本编辑器中打开
/etc/sssd/sssd.conf
文件。 在客户端: 将
ipa_server
选项添加到文件的[domain]
部分,并将其设置为 IdM 服务器。这可避免 IdM 客户端自动发现其他 IdM 服务器,从而将此测试限制为一个客户端和一个服务器。[domain/example.com] ipa_server = server.example.com ...
-
在客户端上: 保存并关闭
sssd.conf
文件。 在客户端上:重启 SSSD 服务以加载配置更改。
[root@client ~]# systemctl restart sssd
在服务器和客户端上:启用详细的 SSSD 调试日志。
[root@server ~]# sssctl debug-level 6
[root@client ~]# sssctl debug-level 6
在服务器和客户端中:为遇到身份验证问题的用户验证 SSSD 缓存中的对象,因此您不用绕过 LDAP 数据库,并检索 SSSD 信息已经缓存。
[root@server ~]# sssctl cache-expire -u idmuser
[root@client ~]# sssctl cache-expire -u idmuser
在服务器和客户端上:通过删除旧的 SSSD 日志来最小化 dataset 故障排除。
[root@server ~]# sssctl logs-remove
[root@server ~]# sssctl logs-remove
在客户端上:尝试切换至遇到身份验证问题的用户,同时在尝试前后收集时间戳。这些时间戳进一步缩小了数据集的范围。
[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
(可选)在服务器和客户端上:如果您不想继续收集详细的 SSSD 日志,请降低 debug 级别。
[root@server ~]# sssctl debug-level 0
[root@client ~]# sssctl debug-level 0
服务器和客户端:查看 SSSD 日志以获取有关失败请求的信息。
- 在客户端日志中查看来自客户端的请求。
- 在服务器日志中查看来自客户端的请求。
- 在服务器日志中检查请求的结果。
- 查看客户端收到来自服务器的请求结果的结果。
如果您无法确定导致身份验证问题的原因:
收集您最近在 IdM 服务器和 IdM 客户端中生成的 SSSD 日志。根据主机名或角色标记它们。
[root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar
[root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar
创建一个红帽技术支持问题单并提供:
SSSD 调试日志:
-
来自服务器的
sssd-logs-server-Mar29.tar
。 -
来自客户端的
sssd-logs-client-Mar29.tar
-
来自服务器的
与日志对应的请求的控制台输出,包括时间戳和用户名:
[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
12.10. 跟踪 SSSD 后端中的客户端请求
SSSD 以异步方式处理请求,并将来自不同请求的消息添加到同一日志文件中,您可以使用唯一的请求标识符和客户端 ID 来在后端日志中追踪客户端请求。唯一请求标识符以 RID#<integer>
形式添加到调试日志中,客户端 ID 以 [CID #<integer]
的形式添加到调试日志中。这可让您隔离与单个请求相关的日志,您可以跨多个 SSSD 组件的日志文件来从头到尾追踪请求。
先决条件
- 您已启用了调试日志,并且已从 IdM 客户端提交了请求。
- 您必须具有 root 特权才能显示 SSSD 日志文件的内容。
流程
要查看 SSSD 日志文件,请使用
less
工具打开日志文件。例如,要查看/var/log/sssd/sssd_example.com.log
:[root@server ~]# less /var/log/sssd/sssd_example.com.log
查看 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
。
但是,对 SSSD 客户端接口的单一客户端请求通常会在后端触发多个请求,因此客户端请求和后端中的请求之间不是 1 对 1 的关系。虽然后端中的多个请求有不同的 RID 号,但每个初始后端请求都包括唯一的客户端 ID,这样管理员就可以通过多个 RID 号追踪到单个客户端请求。
以下示例显示了一个客户端请求 [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].
12.11. 使用日志分析器工具跟踪客户端请求
系统安全服务守护进程(SSSD)包含一个日志解析工具,其可用于跨多个 SSSD 组件的日志文件来从头到尾追踪请求。
12.11.1. 日志分析器工具如何工作
使用日志解析工具,您可以跨多个 SSSD 组件的日志文件来从头到尾追踪 SSSD 请求。您可以使用 sssctl analyze
命令运行分析器工具。
日志分析器工具帮助您解决 SSSD 中的 NSS 和 PAM 问题,并更容易查看 SSSD 调试日志。您只能提取和打印与跨 SSSD 进程的某些客户端请求相关的 SSSD 日志。
SSSD 会从用户身份验证(su
、ssh
)信息来分别追踪用户和组身份信息(id
,getent
)。NSS 响应器中的客户端 ID(CID)与 PAM 响应器中的 CID 无关,在分析 NSS 和 PAM 请求时您会看到重叠的号。使用 sssctl analyze
命令和 --pam
选项来查看 PAM 请求。
从 SSSD 内存缓存返回的请求不会被记录,不能通过日志分析器工具进行追踪。
其它资源
-
sudo sssctl analyze request --help
-
sudo sssctl analyze --help
-
sssd.conf
手册页 -
sssctl
手册页
12.11.2. 运行日志分析器工具
这个流程描述了如何使用日志分析器工具来追踪 SSSD 中的客户端请求。
先决条件
-
您必须在 [$responder] 部分中将
debug_level
设置为至少 7,将/etc/sssd/sssd.conf
文件的 [domain/$domain] 部分设置为启用日志解析功能。 -
要分析的日志必须来自使用支持的
libtevent
链 ID 所构建的 SSSD 的兼容版本,这就是 RHEL 8.5 及之后版本中的 SSSD。
流程
在 list 模式下运行日志分析器工具来确定您在追踪的请求的客户端 ID,添加
-v
选项来显示详细输出:# sssctl analyze request list -v
此时会显示最近对 SSSD 所做的客户端请求的详细列表。
注意如果分析 PAM 请求,请运行
sssctl analyze request list
命令和--pam
选项。使用
show [unique client ID]
选项运行日志分析器工具,来显示与指定客户端 ID 号相关的日志:# sssctl analyze request show 20
如果需要,您可以针对日志文件运行日志分析器工具,例如:
# sssctl analyze request --logdir=/tmp/var/log/sssd
其它资源
-
sssctl analyze request list --help
-
sssctl analyze request show --help
-
sssctl
手册页。
12.12. 其它资源
第 13 章 为单点登录配置应用程序
单点登录(SSO)是一种身份验证模式,允许您通过一个登录流程登录多个系统。您可以将浏览器和电子邮件客户端配置为使用 Kerberos 票据、SSL 认证或令牌来作为对用户进行身份验证的一种方法。
不同应用程序的配置可能有所不同。本章演示了以 Mozilla Thunderbird 电子邮件客户端和 Mozilla Firefox Web 浏览器为例,来如何配置 SSO 身份验证模式。
13.1. 先决条件
您已安装了以下应用程序:
- Mozilla Firefox 版本 88
- Mozilla Thunderbird 版本 78
13.2. 将 Firefox 配置为使用 Kerberos 进行单点登录
您可以将 Firefox 配置为使用 Kerberos 对互联网站点和其他受保护的网站进行单点登录(SSO)。为此,您必须首先配置 Firefox ,来向合适的密钥分发中心(KDC)发送 Kerberos 凭据。
即使 Firefox 被配置为通过了 Kerberos 凭据,它仍需要使用有效的 Kerberos 票据。要生成 Kerberos 票据,请使用 kinit
命令,并在 KDC 上提供用户的密码。
[jsmith@host ~] $ kinit Password for jsmith@EXAMPLE.COM:
流程
-
在 Firefox 的地址栏中,输入
about:config
来显示当前配置选项的列表。 -
在
Filter
字段中,输入negotiate
来限制选项列表。 -
双击
network.negotiate-auth.trusted-uris
条目。 输入要进行身份验证的域的名称,包括前面的句点(.)。如果要添加多个域,请在逗号分隔的列表中输入它们。
图 13.1. 手动 Firefox 配置
其它资源
- 有关在身份管理中配置 Firefox 使用 Kerberos 的详情,请查看 Linux 域身份、身份验证和策略指南中的相应部分。
13.3. 查看 Firefox 中的证书
下面的示例演示了如何查看 Mozilla Firefox 中的证书。
要查看 Firefox 中的证书,您需要打开 证书管理器
。
流程
在 Mozilla Firefox 中,打开 Firefox 菜单,并选择 Preferences。
在左侧面板中,选择
Privacy & Security
部分。-
向下滚动到
Certificates
部分。 单击 View Certificates 来打开
证书管理器
。
13.4. 在 Firefox 中导入 CA 证书
下面的示例演示了如何在 Mozilla Firefox 中导入证书。
先决条件
- 您的设备上已有一个 CA 证书。
要导入 CA 证书:
流程
-
打开
证书管理器
。 选择"
Authorities
选项卡,然后单击 Import 。图 13.2. 在 Firefox 中导入 CA 证书
- 从您的设备中选择下载的 CA 证书。
13.5. 在 Firefox 中编辑证书信任设置
下面的示例演示了如何在 Mozilla Firefox 中编辑证书设置。
先决条件
- 您已成功导入了证书。
要设置证书信任设置:
流程
-
打开
证书管理器
。 -
在
Authorities
选项卡下,选择合适的证书,然后单击 Edit Trust。 编辑证书信任设置。
图 13.3. 在 Firefox 中编辑证书信任设置
13.6. 在 Firefox 中导入用于身份验证的个人证书
下面的示例演示了如何在 Mozilla Firefox 中导入用于身份验证的个人证书。
先决条件
- 您的设备上已存储了一个个人证书。
要使用个人证书进行身份验证:
流程
-
打开
证书管理器
。 选择
Your Certificates
选项卡,然后单击 Import。图 13.4. 在 Firefox 中导入用于身份验证的个人证书
- 从您的计算机上选择合适的证书。
13.7. 查看 Thunderbird 中的证书
以下示例演示了如何查看 Mozilla Thunderbird 电子邮件客户端中的证书。
流程
在 Mozilla Thunderbird 中,打开主菜单并选择
Preferences
。图 13.5. 从菜单中选择首选项
在左侧面板中,选择
Privacy & Security
部分。图 13.6. 选择 security 部分
-
向下滚动到
Certificates
部分。 单击 Manage Certificates 来打开
证书管理器
。图 13.7. 打开证书管理器
13.8. 在 Thunderbird 中导入证书
以下示例演示了如何在 Mozilla Thunderbird 电子邮件客户端中导入证书。
先决条件
- 您的设备上已存储了一个 CA 证书。
要导入 CA 证书:
流程
-
打开
证书管理器
。 选择"
Authorities
选项卡,然后单击 Import 。图 13.8. 在 Thunderbird 中导入 CA 证书
- 选择下载的 CA 证书。
13.9. 在 Thunderbird 中编辑证书信任设置
以下示例演示了如何在 Mozilla Thunderbird 电子邮件客户端中编辑证书设置。
先决条件
- 您已成功导入了证书。
要设置证书信任关系:
流程
-
打开
证书管理器
。 -
在
Authorities
选项卡下,选择合适的证书,然后单击 Edit Trust。 编辑证书信任设置。
图 13.9. 编辑 Thunderbird 中的证书信任设置
13.10. 在 Thunderbird 中导入个人证书
以下示例演示了如何在 Mozilla Thunderbird 电子邮件客户端中导入用于个人身份验证的证书。
先决条件
- 您的设备上已存储了一个个人证书。
要使用个人证书进行身份验证:
流程
-
打开
证书管理器
。 在
Your Certificates
选项卡下,单击 Import。图 13.10. 在 Thunderbird 中导入用于身份验证的个人证书
- 从您的计算机中选择所需的证书。
-
关闭
证书管理器
。 打开主菜单并选择
Account Settings
。图 13.11. 从菜单中选择帐户设置
在您帐户电子邮件地址的左侧面板中选择
End-To-End Encryption
。选择端到端加密部分。
-
在
S/MIME
部分下,单击第一个 Select 按钮,来选择要用于签名消息的个人证书。 在
S/MIME
部分下,单击第二个 Select 按钮,来选择您的个人证书来加密和解密消息。选择用于签名和加密/解密的证书。
如果忘记了导入有效的证书,您可以使用 管理 S/MIME 证书
来直接打开 证书管理器
。