Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
系统级身份验证指南
Red Hat Enterprise Linux 7
使用应用程序和服务在本地系统中配置身份验证
摘要
本指南涵盖了可在本地系统上配置身份验证的不同应用程序和服务。
除了本指南外，您还可以在以下指南中找到与 Red Hat Enterprise Linux 身份管理相关的功能和服务文档：
Linux 域身份、身份验证和策略指南 介绍了红帽身份管理，提供集中且统一的方法来管理身份存储以及基于 Linux 的域中的身份验证和授权策略。
Windows 集成指南 介绍了如何使用身份管理将 Linux 域与 Microsoft Windows Active Directory (AD)集成。在其他主题中，指南涵盖了直接和间接 AD 集成的各个方面，使用 SSSD 访问通用互联网文件系统(CIFS)和 realmd 系统。
第 1 章 系统身份验证简介
建立安全网络环境的基石之一是确保访问权限仅限于那些有权访问网络的人。如果允许访问，用户可以向系统 进行身份验证，这意味着他们可以验证其身份。
在任何 Red Hat Enterprise Linux 系统上，都有多种不同的服务可用来创建和识别用户身份。这些可以是本地系统文件、连接到 Kerberos 或 Samba 等更大身份域的服务，或者用于创建这些域的工具。
本指南回顾了一些可供管理员用于管理本地系统身份验证和身份的通用系统服务和应用程序。其他指南提供了有关 创建 Linux 域 和将 Linux 系统集成到 Windows 域 的更多详细信息。
1.1. 确认用户身份
身份验证 是确认身份的过程。对于网络交互，身份验证涉及由另一方识别双方。可以通过多种方式通过网络使用身份验证：简单密码、证书、一次性密码(OTP)令牌、生物统计扫描。
另一方面，授权 定义允许身份验证方执行的操作或访问权限。
身份验证要求用户提供某种 凭据 来验证其身份。所需的凭证种类由正在使用的身份验证机制定义。系统中的本地用户有几种身份验证：
- 基于密码的身份验证.几乎所有软件都允许用户通过提供可识别名称和密码进行身份验证。这也称为 简单身份验证。
- 基于 证书的身份验证.基于证书的客户端身份验证是 SSL 协议的一部分。客户端通过数字方式为随机生成的数据签名，并在网络上同时发送证书和签名数据。服务器验证签名并确认证书的有效性。
- Kerberos 身份验证.Kerberos 建立了一个短期运行的凭证系统，称为 ticket-granting ticket(TGT)。用户提供用户名和密码，用于标识用户和向系统指示用户可以向系统发出票据。TGT 可被重复用于请求访问票据给其他服务，如网站和电子邮件。使用 TGT 进行身份验证允许用户以这种方式只经历一个验证过程。
- 基于智能卡的验证.这是基于证书的身份验证的一种变体。智能卡（或 令牌）存储用户证书；当用户将令牌插入到系统中时，系统可以读取证书并授予访问权限。使用智能卡的单点登录需要执行三个步骤：
- 用户在卡阅读器中插入智能卡。红帽企业 Linux 上的可插拔验证模块(PAM)检测插入的智能卡。
- 系统将证书映射到用户条目，然后将智能卡上显示的证书（按照基于证书的身份验证中所述使用私钥加密）与用户条目中存储的证书进行比较。
- 如果针对密钥分发中心(KDC)成功验证证书，则允许用户登录。
基于智能卡的验证基于 Kerberos 的简单验证层，通过添加证书作为附加识别机制，并通过添加物理访问要求来构建。
1.2. 作为规划单点登录的一部分
身份验证的内容包括在 第 1.1 节 “确认用户身份” 中，每个安全应用程序都需要输入密码才能访问它。如果没有中央身份存储以及维护其自己的用户和凭证集的每个应用程序，用户必须为其打开的每个服务或应用程序输入密码。这可能需要每天多次输入密码，甚至每几分钟输入一次。
对于用户和管理员而言，维护多个密码并持续提示输入密码非常麻烦。单点登录 是一种配置，允许管理员创建单一密码存储，以便用户可以使用单一密码登录一次，并通过所有网络资源进行身份验证。
红帽企业 Linux 支持多种资源的单点登录，包括登录工作站、解锁屏幕保护程序，以及使用 Mozilla Firefox 访问安全网页。通过 PAM、NSS 和 Kerberos 等其他可用的系统服务，可以将其他系统应用程序配置为使用这些身份源。
单点登录既方便用户，又能为服务器和网络提供另一层安全性。单点登录依赖于安全有效的身份验证.Red Hat Enterprise Linux 提供两种身份验证机制，可用于启用单点登录：
- 基于 Kerberos 域和 Active Directory 域的身份验证
- 基于智能卡的验证
这两种方法都创建一个集中式身份存储（通过 Kerberos 域或公钥基础架构中的证书颁发机构），然后本地系统服务使用这些身份域而不是维护多个本地存储。
1.3. 可用服务
所有 Red Hat Enterprise Linux 系统都具有一些服务，可用于为本地系统上的本地用户配置身份验证。它们是：
- 身份验证设置
- 身份验证配置工具(authconfig)设置不同的身份后端，以及为系统设置身份验证（如密码、指纹或智能卡）的方法。
- 身份备份(Sentity Backd Setup)
- 安全系统服务守护进程(SSSD)设置多个身份提供程序（主要基于 LDAP 的目录，如 Microsoft Active Directory 或 Red Hat Enterprise Linux IdM），然后可由本地系统和应用程序供用户使用。密码和票据将被缓存，允许通过重复使用凭据进行离线身份验证和单点登录。
- realmd 服务是一个命令行工具，允许您配置身份验证后端，这是 IdM 的 SSSD。realmd 服务根据 DNS 记录检测可用的 IdM 域，配置 SSSD，然后将系统作为帐户加入到域中。
- 名称服务切换(NSS)是用于返回有关用户、组或主机信息的低级别系统调用的机制。NSS 确定应该使用哪个源（即哪些模块）来获取所需的信息。例如，用户信息可以位于传统的 UNIX 文件中，如
/etc/passwd文件，或者在基于 LDAP 的目录中，而主机地址可以从文件读取，如/etc/hosts文件或 DNS 记录；NSS 查找信息存储位置。
- 身份验证机制
- 可插拔验证模块(PAM)提供用于设置身份验证策略的系统。使用 PAM 进行身份验证的应用加载控制不同身份验证方面的不同模块；应用所使用的 PAM 模块则基于应用的配置方式。可用的 PAM 模块包括 Kerberos、Winbind 或本地基于 UNIX 文件的身份验证。
还提供其他服务和应用，但它们很常见。
部分 I. 系统登录
这部分提供了如何使用
authconfig、ipa-client-install 和 realmd 工具配置系统身份验证的说明。
第 2 章 配置系统身份验证
身份验证 是向系统识别并验证用户的过程。它需要显示某种身份和凭据，如用户名和密码。然后，系统将凭据与配置的验证服务进行比较。如果凭据匹配并且用户帐户处于活动状态，则该用户将 进行身份验证。
用户通过身份验证后，信息将传递到访问控制服务，以确定允许用户执行的操作。这些是用户 有权 访问的资源。请注意，身份验证和授权是两个独立的进程。
系统必须具有已配置的有效帐户数据库列表，才能检查用户身份验证。要验证用户的信息可以位于本地系统中，或者本地系统可以引用远程系统（如 LDAP 或 Kerberos）中的用户数据库。本地系统可以将各种数据存储用于用户信息，包括轻量级目录访问协议(LDAP)、网络信息服务(NIS)和 Winbind。LDAP 和 NIS 数据存储都可以使用 Kerberos 对用户进行身份验证.
为了方便且可能属于单点登录，Red Hat Enterprise Linux 可以使用系统安全服务守护进程(SSSD)作为中央守护进程，将用户验证到不同的身份后端，甚至向用户请求一个票据获取票据(TGT)。SSSD 可以与 LDAP、Kerberos 和外部应用程序交互以验证用户凭证。
本章解释了 Red Hat Enterprise Linux 中可用于配置系统身份验证的工具：
- 其它系统的
authconfig工具和 authconfig UI ；如需更多信息，请参阅 第 2.2 节 “使用authconfig”
2.1. 系统身份验证的身份管理工具
您可以使用
ipa-client-install 工具和 realmd 系统来在身份管理机器上自动配置系统身份验证。
2.2. 使用 authconfig
authconfig 工具可帮助配置要用于用户凭据的数据存储，如 LDAP。在 Red Hat Enterprise Linux 中，
authconfig 同时具有 GUI 和命令行选项来配置任何用户数据存储。authconfig 工具可将系统配置为使用特定服务 - SSSD、LDAP、NIS 或 Winbind - 用于其用户数据库，以及使用不同类型的身份验证机制。
重要
要配置身份管理系统，红帽建议使用
ipa-client-install 工具或 realmd 系统，而不是 authconfig。authconfig 工具有限且更灵活。如需更多信息，请参阅 第 2.1 节 “系统身份验证的身份管理工具”。
以下三个
authconfig 工具可用于配置身份验证设置：
authconfig-gtk提供完整的图形界面。authconfig为手动配置提供命令行界面。authconfig-tui提供基于文本的 UI。请注意，这个工具已弃用。
所有这些配置工具必须以
root 用户身份运行。
2.2.1. 使用 authconfig CLI 提示
authconfig 命令行工具根据传递给脚本的设置更新系统身份验证所需的所有配置文件和服务。除了通过 UI 设置更多身份和身份验证配置选项外，authconfig 工具也可用于创建备份和 kickstart 文件。
有关 authconfig 选项的完整列表，请查看帮助输出和 man page。
运行 authconfig 时需要记住一些问题：
- 对于每个命令，请使用
--update或--test选项。命令需要其中一个选项才能成功运行。使用--update写入配置更改。test 选项显示更改，但不将更改应用到配置。如果没有使用--update选项，则不会将更改写入系统配置文件。 - 命令行可用于更新现有配置并设置新配置。因此，命令行不会强制将所需的属性用于给定调用（因为 命令可能正在更新其他完整的设置）。编辑身份验证配置时，请非常小心，确保配置完整准确。将身份验证设置更改为不完整或错误值可将用户锁定在系统之外。在使用 --update 选项写入前，使用 --test 选项确认设置正确。
- 每个启用选项都有对应的 disable 选项。
2.2.2. 安装 authconfig UI
默认情况下，未安装 authconfig UI，但管理员对身份验证配置进行快速更改非常有用。
要安装 UI，请安装
authconfig-gtk 软件包。这对一些常见的系统软件包有依赖项，如 authconfig 命令行工具、Bash 和 Python。其中大多数默认安装。
[root@server ~]# yum install authconfig-gtk Loaded plugins: langpacks, product-id, subscription-manager Resolving Dependencies --> Running transaction check ---> Package authconfig-gtk.x86_64 0:6.2.8-8.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: authconfig-gtk x86_64 6.2.8-8.el7 RHEL-Server 105 k Transaction Summary ================================================================================ Install 1 Package ... 8< ...
2.2.3. 启动 authconfig UI
- 打开终端，再以 root 用户身份登录。
- 运行 system-config-authentication 命令。
重要
当 authconfig UI 关闭时，任何更改都会立即生效。
Authentication 对话框中有三个配置标签页：
- 身份和身份验证，用于配置用作身份存储的资源（存储用户 ID 和对应凭证的数据仓库）。
- 高级选项，它配置密码或证书以外的身份验证方法，如智能卡和指纹。
- 密码选项，用于配置密码验证方法。
图 2.1. authconfig Window
2.2.4. 测试身份验证设置
充分且正确配置了身份验证非常重要。否则，所有用户（甚至 root 用户）都可以被锁定在系统之外，或者某些用户被阻止。
test
选项 会针对每一种可能的身份和身份验证机制打印系统的所有身份验证配置。这会显示已启用的设置以及哪些区域被禁用。
测试 选项可以自行运行，以显示完整的、当前配置，或者可与 authconfig 命令一起使用来显示 配置是如何更改（实际上没有更改 ）。这对于验证建议的验证设置是否完整且正确非常有用。
[root@server ~]# authconfig --test caching is disabled nss_files is always enabled nss_compat is disabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is disabled LDAP+TLS is disabled LDAP server = "" LDAP base DN = "" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "MYGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap range = "16777216-33554431" nss_sss is enabled by default nss_wins is disabled nss_mdns4_minimal is disabled DNS preference over NSS or WINS is disabled pam_unix is always enabled shadow passwords are enabled password hashing algorithm is sha512 pam_krb5 is disabled krb5 realm = "#" krb5 realm via dns is disabled krb5 kdc = "" krb5 kdc via dns is disabled krb5 admin server = "" pam_ldap is disabled LDAP+TLS is disabled LDAP server = "" LDAP base DN = "" LDAP schema = "rfc2307" pam_pkcs11 is disabled use only smartcard for login is disabled smartcard module = "" smartcard removal action = "" pam_fprintd is disabled pam_ecryptfs is disabled pam_winbind is disabled SMB workgroup = "MYGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_sss is disabled by default credential caching in SSSD is enabled SSSD use instead of legacy services if possible is enabled IPAv2 is disabled IPAv2 domain was not joined IPAv2 server = "" IPAv2 realm = "" IPAv2 domain = "" pam_pwquality is enabled (try_first_pass local_users_only retry=3 authtok_type=) pam_passwdqc is disabled () pam_access is disabled () pam_mkhomedir or pam_oddjob_mkhomedir is disabled (umask=0077) Always authorize local users is enabled () Authenticate system accounts against network services is disabled
2.2.5. 使用 authconfig保存和恢复配置
更改身份验证设置可能会产生问题。不正确的更改配置可能会错误地排除应具有访问权限的用户，可能会导致与身份存储的连接失败，甚至可能会锁定对系统的所有访问。
在编辑身份验证配置之前，强烈建议管理员备份所有配置文件。这通过
--savebackup 选项完成。
[root@server ~]# authconfig --savebackup=/backups/authconfigbackup20200701
身份验证配置可以使用
--restorebackup 选项及要使用的备份名称恢复到之前保存的任何版本。
[root@server ~]# authconfig --restorebackup=/backups/authconfigbackup20200701
当每次更改配置时，authconfig 命令都会保存自动备份。可以使用
--restorelastbackup 选项恢复最后的备份。
[root@server ~]# authconfig --restorelastbackup
第 3 章 选择 Identity Store for Authentication with authconfig
authconfig UI 中的 Identity & Authentication 选项卡设置用户应该如何进行身份验证。默认设置是使用本地系统身份验证，即对照本地系统帐户检查用户及其密码。Red Hat Enterprise Linux 计算机还可以使用包含用户和凭证的外部资源，包括 LDAP、NIS 和 Winbind。
3.1. IPAv2
可以通过两种不同的方式将身份管理服务器配置为身份后端。对于 IdM 版本 2 (Red Hat Enterprise Linux 6.3 及更早版本)、版本 3 （在 Red Hat Enterprise Linux 6.4 及更高版本中）和版本 4 （在 Red Hat Enterprise Linux 7.1 及更高版本中），它们在
authconfig 中被配置为 IPAv2 供应商。对于以前的 IdM 版本和社区 FreeIPA 服务器，它们被配置为 LDAP 提供程序。
3.1.1. 使用 UI 配置 IdM
- 打开 authconfig UI。
- 在 User Account Database 下拉菜单中选择 。
图 3.1. 身份验证配置
- 设置连接到 IdM 服务器所需的信息。
- IPA 域 提供 IdM 域的 DNS 域。
- IPA Realm 提供 IdM 域的 Kerberos 域。
- IPA 服务器提供 IdM 域拓扑中任何 IdM 服务器的主机名。
- 不要配置 NTP （可选）在客户端配置时禁用 NTP 服务。这通常不建议，因为 IdM 服务器和所有客户端都需要同步时钟以便 Kerberos 身份验证和证书正常工作。如果 IdM 服务器使用不同的 NTP 服务器，而不是在域中托管它，这可以禁用。
- 点 按钮。这运行 ipa-client-install 命令，如果需要，会安装
ipa-client软件包。安装脚本自动配置本地系统所需的所有系统文件，并联系域服务器以更新域信息。
3.1.2. 从命令行配置 IdM
IdM 域将多个常见和关键服务集中到一个层次结构中，最重要的是 DNS 和 Kerberos。
authconfig （类似于 第 8 章 使用
realmd 连接到身份域中的 realmd ）可用于在 IdM 域中注册系统。运行 ipa-client-install 命令，如果需要，会安装 ipa-client 软件包。安装脚本自动配置本地系统所需的所有系统文件，并联系域服务器以更新域信息。
加入域需要三段信息来标识域：DNS 域名(
--ipav2domain)、Kerberos 域名称(--ipav2realm)和要联系的 IdM 服务器(--ipav2server)。--ipav2join 选项提供用于连接到 IdM 服务器的管理员用户名；这通常是 admin。
[root@server ~]# authconfig --enableipav2 --ipav2domain=IPAEXAMPLE --ipav2realm=IPAEXAMPLE --ipav2server=ipaexample.com --ipav2join=admin
如果 IdM 域没有运行自己的 NTP 服务，则可以使用
--disableipav2nontp 选项来防止设置脚本使用 IdM 服务器作为 NTP 服务器。这通常不建议，因为 IdM 服务器和所有客户端都需要同步时钟才能使 Kerberos 身份验证和证书正常工作。
3.2. LDAP 和 IdM
标准 LDAP 目录（如 OpenLDAP 和红帽目录服务器）都可用作 LDAP 身份提供商。另外，旧的 IdM 版本和 FreeIPA 也可以配置为身份提供程序，方法是将其配置为具有相关 Kerberos 服务器的 LDAP 供应商。
openldap-clients 软件包或 sssd 软件包用于为用户数据库配置 LDAP 服务器。默认情况下会安装这两个软件包。
3.2.1. 使用 UI 配置 LDAP 身份验证
- 打开
authconfigUI，如 第 2.2.3 节 “启动 authconfig UI” 所述。 - 在 用户帐户数据库 下拉菜单中选择 。
- 设置连接 LDAP 服务器所需的信息。
- LDAP 搜索基础 DN 提供用户目录的 root 后缀或可 区分名称 (DN)。用于身份或身份验证的所有用户条目都位于此父条目的下方。例如，
ou=people,dc=example,dc=com。此字段是可选的。如果没有指定，系统安全服务守护进程(SSSD)会尝试使用 LDAP 服务器配置条目中namingContexts和defaultNamingContext属性检测搜索基础。 - LDAP 服务器提供 LDAP 服务器的 URL。这通常需要 LDAP 服务器的主机名和端口号，如
ldap://ldap.example.com:389。使用以ldaps://开头的 URL 输入安全协议，可启用 按钮，该按钮从发布的任何证书颁发机构中检索 LDAP 服务器的 CA 证书。CA 证书必须采用隐私增强的邮件(PEM)格式。 - 如果您使用不安全的标准端口连接( 以
ldap://开头的URL)，您可以使用 Use TLS 加密连接 复选框来使用STARTTLS加密与 LDAP 服务器通信。选择此复选框也会启用 按钮。注意如果服务器 URL 使用 LDAPS (LDAP over SSL)安全协议，则不需要选择 Use TLS 来加密连接 复选框，因为通信已经加密。
- 选择验证方法。LDAP 允许简单密码身份验证或 Kerberos 身份验证.第 4.3.1 节 “使用 UI 配置 Kerberos 身份验证” 中描述了使用 Kerberos。LDAP 密码 选项使用 PAM 应用程序使用 LDAP 身份验证。此选项要求通过使用 LDAPS 或 TLS 连接到 LDAP 服务器来设置安全连接。
3.2.2. 从命令行配置 LDAP 用户存储
要使用 LDAP 身份存储，请使用
--enableldap。要将 LDAP 用作身份验证源，请使用 --enableldapauth，然后使用必要的连接信息，如 LDAP 服务器名称、用户后缀的基础 DN，以及（可选）是否使用 TLS。authconfig 命令还具有为用户条目启用或禁用 RFC 2307bis 模式的选项，这无法通过 authconfig UI 实现。
务必使用完整的 LDAP URL，包括协议(ldap 或 ldaps)和端口号。不要将 安全 LDAP URL (ldaps)与
--enableldaptls 选项一起使用。
authconfig --enableldap --enableldapauth --ldapserver=ldap://ldap.example.com:389,ldap://ldap2.example.com:389 --ldapbasedn="ou=people,dc=example,dc=com" --enableldaptls --ldaploadcacert=https://ca.server.example.com/caCert.crt --update
除了使用
--ldapauth 进行 LDAP 密码身份验证外，可以将 Kerberos 用于 LDAP 用户存储。这些选项在 第 4.3.2 节 “从命令行配置 Kerberos 身份验证” 中描述。
3.3. NIS
重要
在将 NIS 配置为身份存储之前，必须针对环境配置 NIS 本身：
- NIS 服务器必须使用设置的用户帐户进行完全配置。
- ypbind 软件包必须安装在本地系统上。NIS 服务需要此设置，但默认情况下不安装。
portmap和ypbind服务已启动，并在引导时启用。这应该配置为 ypbind 软件包安装的一部分。
3.3.1. 通过 UI 配置 NIS 身份验证
- 打开 authconfig UI，如 第 2.2.3 节 “启动 authconfig UI” 所述。
- 在 用户帐户数据库 下拉菜单中选择 。
- 将信息设置为连接到 NIS 服务器，即 NIS 域名和服务器主机名。如果没有指定 NIS 服务器，则 authconfig 守护进程会扫描 NIS 服务器。
- 选择验证方法。NIS 允许简单密码验证或 Kerberos 验证.第 4.3.1 节 “使用 UI 配置 Kerberos 身份验证” 中描述了使用 Kerberos。
3.3.2. 从命令行配置 NIS
要使用 NIS 身份存储，请使用
--enablenis。这会自动使用 NIS 验证，除非明确设置了 Kerberos 参数(第 4.3.2 节 “从命令行配置 Kerberos 身份验证”)。唯一参数是识别 NIS 服务器和 NIS 域；如果不使用这些参数，则 authconfig 服务会为 NIS 服务器扫描网络。
[root@server ~]# authconfig --enablenis --nisdomain=EXAMPLE --nisserver=nis.example.com --update
3.4. winbind
必须配置 Samba，然后才能将 Winbind 配置为系统的身份存储。必须设置 Samba 服务器并将其用于用户帐户，或者 Samba 必须配置为使用 Active Directory 作为后端身份存储。
Samba 项目文档中介绍了配置 Samba。Windows 集成指南中的"使用 Samba for Active Directory 集成"一节中介绍了将 Samba 配置为 Active Directory 集成 的集成点。
3.4.1. 在 authconfig GUI 中启用 Winbind
- 安装
samba-winbind软件包。Samba 服务中的 Windows 集成功能需要此功能，但不默认安装。[root@server ~]# yum install samba-winbind
- 打开 authconfig UI。
[root2server ~]# authconfig-gtk
- 在 Identity & Authentication 选项卡中，在 User Account Database 下拉菜单中选择 。
- 设置连接 Microsoft Active Directory 域控制器所需的信息。
- winbind 域 提供要连接的 Windows 域。这应该为 Windows 2000 格式，如 DOMAIN。
- 安全模型 设置用于 Samba 客户端的安全模型。authconfig 支持四种安全模型：
- ads 将 Samba 配置为充当 Active Directory Server 域中的域成员。若要在此模式下操作，必须安装
krb5-server软件包，并且必须正确配置 Kerberos。 - 域 具有 Samba 通过 Windows 主或备份域控制器（与 Windows 服务器）进行身份验证来验证用户名和密码。
- 服务器 具有本地 Samba 服务器，方法是通过其他服务器（如 Windows 服务器）进行验证来验证用户名和密码。如果服务器身份验证尝试失败，系统会尝试使用 用户模式 进行身份验证。
- 用户 要求客户端使用有效的用户名和密码登录。此模式支持加密的密码。用户名格式必须是 domain\user，如 EXAMPLE\jsmith。注意当验证给定用户是否在 Windows 域中存在时，始终使用
domain\user_name格式并转义反斜杠(\)字符。例如：[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
这是默认选项。
- winbind ADS Realm 提供 Samba 服务器要加入的活动目录域。这仅用于 ads 安全模型。
- winbind 域控制器 提供用于注册系统的域控制器的主机名或 IP 地址。
- Template Shell 设置用于 Windows 用户帐户设置的登录 shell。
- 允许离线登录 允许将身份验证信息存储在本地缓存中。当用户尝试在系统离线时对系统资源进行身份验证时，会引用缓存。
3.4.2. 在命令行中启用 Winbind
Windows 域具有几种不同的安全模型，域中使用的安全模型决定了本地系统的身份验证配置。对于用户和服务器安全模型，Winbind 配置仅需要域（或工作组）名称和域控制器主机名。
--winbindjoin 参数设置用于连接到 Active Directory 域的用户，-- enablelocalauthorize 设置本地授权操作来检查 /etc/passwd 文件。
运行 authconfig 命令后，加入 Active Directory 域。
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity=user|server --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --update --enablelocauthorize --winbindjoin=admin [root@server ~]# net join ads
注意
用户名格式必须是 domain\user，如 EXAMPLE\jsmith。
验证 Windows 域中是否存在给定用户时，始终使用 domain\user 格式并转义反斜杠(\)字符。例如：
[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
对于 ads 和域安全模型，Winbind 配置允许对模板 shell 和 realm（仅限用户）进行额外的配置。例如：
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity ads --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --smbrealm EXAMPLE.COM --winbindtemplateshell=/bin/sh --update
还有许多其他选项可用于配置基于 Windows 的身份验证，以及 Windows 用户帐户的信息，如名称格式、是否需要使用用户名的域名以及 UID 范围。这些选项列在 authconfig 帮助中。
第 4 章 配置身份验证机制
Red Hat Enterprise Linux 支持多种不同的身份验证方法。它们可以使用
authconfig 工具进行配置，或者在某些情况下，也可以使用身份管理工具进行配置。
4.1. 使用 authconfig配置本地身份验证
Local Authentication Options 区域定义了本地系统帐户的设置，而不是存储在后端上的用户。这些设置定义系统服务基于用户的授权（如
/etc/security/access.conf中定义的）。否则，可以在身份提供程序或服务本身中定义授权策略。
4.1.1. 在 UI 中启用本地访问控制
启用本地访问控制 设置系统，以检查
/etc/security/access.conf 文件是否有本地用户授权规则。这是 PAM 授权。
图 4.1. 本地帐户字段
4.1.2. 在命令行中配置本地访问控制
authconfig 有两个选项，可以启用本地授权控制。
--enablelocauthorize 跳过网络身份验证，仅检查系统用户的本地文件。--enablepamaccess 将系统配置为在 /etc/security/access.conf 中查找系统授权策略。
[root@server ~]# authconfig --enablelocauthorize --enablepamaccess --update
4.2. 使用 authconfig配置系统密码
4.2.1. 密码安全性
如果密码以纯文本格式存储，它们很容易被破解、未经授权的访问或篡改。为防止这种情况，可以使用加密哈希算法安全地存储密码哈希摘要。IdM 中支持的推荐哈希算法是 SHA-512，它使用 64 位词语，以及 salt 和扩展来实现额外的安全性。为确保向后兼容，还支持 SHA-256、DES、BigCrypt 和 MD5 哈希算法。
重要
如果您不需要向后兼容，请只使用 SHA-512，因为它更安全。
4.2.1.1. 在 UI 中配置密码哈希
Local Authentication Options 选项卡设置如何保存本地密码。Password Hashing Algorithm 下拉菜单将算法设置为安全地存储密码哈希。
- 打开 authconfig UI，如 第 2.2.3 节 “启动 authconfig UI” 所述。
- 打开 Advanced Options 选项卡。
- 选择在 Password Hashing Algorithm 下拉菜单中使用的算法。
- 按钮。
4.2.1.2. 在命令行中配置密码哈希
要设置或更改用于安全存储用户密码摘要的哈希算法，请使用
--passalgo 选项和算法的短名称。以下示例使用 SHA-512 算法：
[root@server ~]# authconfig --passalgo=sha512 --update
4.2.2. 密码复杂性
密码复杂性 设置本地用户帐户必须允许密码的强程度。复杂性是长度和字符类变化的组合。查看它的一种方式是，有两个部分可以为复杂密码设置策略：确定哪些字符类型可以在密码中使用（如大写字母和小写字母及特殊字符），以及在密码中使用这些字符的方式（必须持续多长时间，以及这些字符可以重复的频率）。
4.2.2.1. 在 UI 中配置密码复杂性
- 打开 authconfig UI，如 第 2.2.3 节 “启动 authconfig UI” 所述。
- 打开 Password Options 选项卡。
- 为密码设置 最低要求 ：
- 密码的最小长度
- 密码必须使用的最小字符类数。
- 启用 必须 用于密码的字符类。例如，大写字母可以与任何密码一起使用，但如果选择了 Uppercase 复选框，则每个密码都必须使用大写字母。
- 设置字符类可以连续重复的次数。（如果设置为零，则没有重复限制。）对于 相同的 Character 字段，这设置可重复单个字母或字符的频率。例如，如果设置为 2，则允许 ssecret，但 sssecret 被拒绝。同样，同类 会对字符类（大写、数字、特殊字符）的任意字符的多次设置限制。例如，如果设置为 3，secret!! 是允许的，但 secret!@ 或 secret1234 将被拒绝。
- 按钮。
4.2.2.2. 在命令行中配置密码复杂性
在注释行中定义密码复杂性时，有两个半值用于设置要求。第一种方法是设置有关如何构建密码的要求（密码长度、字符长度、必须重复的字符数）以及必须使用的不同类型的字符：
- 最小长度(
--passminlen)。 - 必须使用的不同类型的字符的最小数量(
--passminclass)。 - 字符可以连续重复的次数(
--passmaxrepeat)。将它设置为零表示没有重复限制。 - 可以在一行中使用相同类型的字符（如数字）的时间数(--
passmaxclassrepeat)。将它设置为零表示没有重复限制。
第二半是定义允许用于密码的字符类型或类别。所有字符类型都是隐式允许的；使用
--enablereqType 选项表示绝对必需一个给定类，或者拒绝密码。（相反，还可明确拒绝类型。）
- 大写字母(--
enablerequpper) - 小写字母(
--enablereqlower) - 数字(
--enablereqdigit) - 特殊字符(
--enablereqother)
例如，这设置最少 9 个字符的长度，不允许字符或类重复两次，并且需要大写和特殊字符。
[root@server ~]# authconfig --passminlen=9 --passminclass=3 --passmaxrepeat=2 -passmaxclassrepeat=2 --enablerequpper --enablereqother --update
4.3. 使用 authconfig配置 Kerberos （使用 LDAP 或 NIS）
LDAP 和 NIS 验证存储均支持 Kerberos 验证方法。使用 Kerberos 有几个优点：
- 它使用安全层进行通信，同时仍然允许通过标准端口进行连接。
- 它自动将凭证缓存与 SSSD 搭配使用，允许离线登录。
注意
使用 Kerberos 身份验证需要
krb5-libs 和 krb5-workstation 软件包。
4.3.1. 使用 UI 配置 Kerberos 身份验证
身份验证方法 下拉菜单中的 选项会自动打开连接到 Kerberos 域所需的字段。
图 4.2. Kerberos 字段
- realm 提供 Kerberos 服务器的域的名称。realm 是使用 Kerberos 的网络，由一个或多个 关键分发中心( KDC)和潜在的大量客户端组成。
- KDC 提供以逗号分隔的服务器列表，用于发出 Kerberos 票据。
- 管理服务器 提供了在域中运行 kadmind 进程的管理服务器列表。
- （可选）使用 DNS 解析服务器主机名并在域中查找其他 KDC。
4.3.2. 从命令行配置 Kerberos 身份验证
LDAP 和 NIS 允许使用 Kerberos 身份验证代替其原生验证机制。至少，使用 Kerberos 身份验证时，需要指定域、KDC 和管理服务器。还可以使用 DNS 解析客户端名称并查找额外的管理服务器。
[root@server ~]# authconfig NIS or LDAP options --enablekrb5 --krb5realm EXAMPLE --krb5kdc kdc.example.com:88,server.example.com:88 --krb5adminserver server.example.com:749 --enablekrb5kdcdns --enablekrb5realmdns --update
4.4. 智能卡
基于智能卡进行验证是替代基于密码的身份验证。用户凭证存储在智能卡中，然后使用特殊的软件和硬件来访问它们。要使用智能卡进行身份验证，用户必须将智能卡放在智能卡读取器中，然后提供智能卡的 PIN 代码。
重要
下面的部分论述了如何使用 pam_pkcs11 和 pam_krb5 软件包为本地用户配置智能卡验证系统。请注意，这些软件包现在已弃用，如 7.4 发行注记 中的 Deprecated Functionality 所述。
要集中配置智能卡身份验证，请使用系统安全服务守护进程(SSSD)提供的增强智能卡功能。详情请参阅 Linux 域 身份、身份验证和策略指南中 的身份管理中的智能卡 身份验证。
4.4.1. 使用 authconfig配置智能卡
选择 启用智能卡支持 选项后，会显示其他控制来配置智能卡的行为。
图 4.3. 智能卡选项
请注意，默认情况下不启用 Red Hat Enterprise Linux 服务器和工作站的智能卡登录，且必须在系统设置中启用。
注意
登录 Red Hat Enterprise Linux 时使用单点登录需要这些软件包：
- nss-tools
- nss-pam-ldapd
- esc
- pam_pkcs11
- pam_krb5
- opensc
- pcsc-lite-ccid
- gdm
- authconfig
- authconfig-gtk
- krb5-libs
- krb5-workstation
- krb5-pkinit
- pcsc-lite
- pcsc-lite-libs
4.4.1.1. 从 UI 启用智能卡身份验证
- 以 root 用户身份登录系统。
- 以基础 64 格式下载网络的 root CA 证书，并将它们安装在服务器上。证书使用 certutil 命令在适当的系统数据库中安装。例如：
[root@server ~]# certutil -A -d /etc/pki/nssdb -n "root CA cert" -t "CT,C,C" -i /tmp/ca_cert.crt
注意不要担心导入的证书稍后不会在authconfigUI 中显示。您不能在 UI 中看到证书；在身份验证过程中，它从/etc/pki/nssdb/目录中获取。 - 在顶部菜单中选择 菜单，选择 ，然后单击 。
- 打开 Advanced Options 选项卡。
- 点 Enable Smart Card Support 复选框。
- 可以为智能卡配置两种行为：
- Card removal 操作 菜单在活跃会话中删除智能卡时设定系统所采取的响应。
Ignore选项表示，如果删除了智能卡，系统将继续正常运行，而Lock会立即锁定屏幕。 - Require smart card for login 复选框设定了登录是否需要智能卡。选择此选项时，所有其他身份验证方法都将被阻止。警告在成功使用智能卡登录 后，不要选择此项。
- 默认情况下，检查证书是否已撤销（在线证书状态协议或 OCSP 响应）的机制已被禁用。要验证证书是否在过期前撤销，请通过在
cert_policy指令中添加ocsp_on选项来启用 OCSP 检查。- 打开
pam_pkcs11.conf文件。vim /etc/pam_pkcs11/pam_pkcs11.conf
- 更改每个
cert_policy行，使其包含ocsp_on选项。cert_policy = ca,
ocsp_on,signature;注意由于文件被解析的方式，cert_policy 和等号之间必须有一个空格。否则，解析参数会失败。
- 如果智能卡尚未注册（使用个人证书和密钥设置），请注册智能卡。
- 如果智能卡是 CAC 卡，请在 CAC 用户的主目录中创建
.k5login文件。.k5login文件需要在 CAC 卡上具有 Microsoft Principal Name。 - 在
/etc/pam.d/smartcard-auth和/etc/pam.d/system-auth文件中添加以下行：auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
如果 OpenSC 模块无法按预期工作，请使用 coolkey 软件包中的模块：/usr/lib64/pkcs11/libcoolkeypk11.so。在这种情况下，请考虑联系红帽技术支持或就该问题发布 Bugzilla 报告。 - 配置
/etc/krb5.conf文件。设置根据您是使用 CAC 卡还是 Gemalto 64K 卡而有所不同。- 使用 CAC 卡，在
pkinit_anchors中指定与 CAC 卡使用相关的所有根证书。在用来配置 CAC 卡的/etc/krb5.conf文件中，EXAMPLE.COM 是 CAC 卡的域名称，kdc.server.hostname.com 是 KDC 服务器主机名。[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 dns_lookup_kdc = false ticket_lifetime = 1h renew_lifetime = 6h forwardable = true default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.server.hostname.com admin_server = kdc.server.hostname.com pkinit_anchors = FILE:/etc/pki/nssdb/ca_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_email_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_root_ca_cert.pem pkinit_cert_match = CAC card specific information } [domain_realm] EXAMPLE.COM = EXAMPLE.COM .EXAMPLE.COM = EXAMPLE.COM .kdc.server.hostname.com = EXAMPLE.COM kdc.server.hostname.com = EXAMPLE.COM [appdefaults] pam = { debug = true ticket_lifetime = 1h renew_lifetime = 3h forwardable = true krb4_convert = false mappings = username on the CAC card Principal name on the card } - 在用来配置 Gemalto 64K 卡的
/etc/krb5.conf文件中，EXAMPLE.COM 是 KDC 服务器上创建的域，kdc-ca.pem 是 CA 证书，kdc.server.hostname.com 是 KDC 服务器主机名。[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 dns_lookup_kdc = false ticket_lifetime = 15m renew_lifetime = 6h forwardable = true default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.server.hostname.com admin_server = kdc.server.hostname.com pkinit_anchors = FILE:/etc/pki/nssdb/kdc-ca.pem pkinit_cert_match = <KU>digitalSignature pkinit_kdc_hostname = kdc.server.hostname.com } [domain_realm] EXAMPLE.COM = EXAMPLE.COM .EXAMPLE.COM = EXAMPLE.COM .kdc.server.hostname.com = EXAMPLE.COM kdc.server.hostname.com = EXAMPLE.COM [appdefaults] pam = { debug = true ticket_lifetime = 1h renew_lifetime = 3h forwardable = true krb4_convert = false }
注意
当插入智能卡时，pklogin_finder 工具以 debug 模式运行，首先将登录 ID 映射到卡中的证书，然后尝试输出证书的有效性信息：
pklogin_finder debug
命令可用于诊断使用智能卡登录系统的问题。
4.4.1.2. 从命令行配置智能卡身份验证
在系统中使用智能卡所需的一切是设置
--enablesmartcard 选项：
[root@server ~]# authconfig --enablesmartcard --update
智能卡还有其他配置选项，如更改默认智能卡模块、设置智能卡删除时的系统行为，以及登录需要智能卡。
如果删除了智能卡，值为 0 会指示系统立即锁定用户；如果删除了智能卡，1 会忽略它：
[root@server ~]# authconfig --enablesmartcard --smartcardaction=0 --update
智能卡验证成功配置和测试后，便可将系统配置为要求用户进行智能卡验证，而不是简单的基于密码的身份验证。
[root@server ~]# authconfig --enablerequiresmartcard --update
警告
除非您使用智能卡成功验证了系统的身份验证，否则请勿使用
--enablerequiresmartcard 选项。否则，用户可能无法登录系统。
4.4.2. 身份管理中的智能卡身份验证
Red Hat Identity Management 支持 IdM 用户的智能卡验证。如需更多信息，请参阅 Linux 域 身份、身份验证和策略指南中 的身份管理智能卡 身份验证一节。
4.4.3. 支持的智能卡
Red Hat Enterprise Linux 支持以下智能卡和读取器。
智能卡
- Athena ASECard Crypto smart, pkcs15-unit
- ATOS(Siemens)CardOS 5.0
- Gemalto ID Classic 230 / TOP IM CY2 64kv2
- Gemalto Cyberflex Access 64k V2c
- Gemalto GemPCKey USB 组成因素
- Giesecke & Devrient(G&D)SmartCafe Professional 6.0(SCP03)
- Giesecke & Devrient(G&D)SmartCafe Professional 7.0(SCP03)
- Safenet 330J
- Safenet SC650(SCP01)
- Siemens Card CardOS M4.4
- YubiKey 4
读取器
- 带有内置智能卡读取器的 HP Keyboard KUS1206
- Omnikey 3121 reader
- Omnikey 3121，PID 为 0x3022 读取器
- Reiner SCT NetworkJack RFID komfort reader
- SCR331 CCID 读取器
4.5. 一次性密码
一次性密码(OTP)是仅对一个身份验证会话有效的密码，在使用后会变得无效。与在较长时间内保持不变的传统静态密码不同，OTP 会持续变化。OTPS 作为双因素验证的一部分：第一步要求用户使用传统的静态密码进行身份验证，第二步则提示输入由识别的身份验证令牌发布的 OTP。
使用 OTP 组合使用静态密码进行身份验证被视为比仅使用静态密码进行身份验证更为安全。因为 OTP 只能用于成功进行身份验证一次，即使潜在的入侵者在登录期间截获了 OTP，因此被拦截的 OTP 已无效。
Red Hat Enterprise Linux 中的一次性密码
Red Hat Identity Management 支持 IdM 用户的 OTP 身份验证。如需更多信息，请参阅 Linux 域身份、身份验证和策略指南中 的一次性密码 章节。
4.6. 使用 authconfig配置指纹
4.6.1. 在 UI 中使用指纹身份验证
当有适当的硬件可用时，启用指纹读取器支持选项 允许在其他凭证之外使用指纹扫描来验证本地用户。
图 4.4. 指纹选项
4.6.2. 在命令行中配置指纹身份验证
有一个选项可用于启用对指纹读取器的支持。这个选项可以单独使用，也可以与其他
authconfig 设置一起使用，如 LDAP 用户存储。
[root@server ~]# authconfig --enablefingerprint --update
第 5 章 使用 authconfig管理 Kickstart 和配置文件
update 选项 使用配置更改更新所有配置文件。有几个备用选项具有略微不同的行为：
--kickstart将更新的配置写入 kickstart 文件。--test使用更改显示完整的配置，但不编辑任何配置文件。
另外，
authconfig 可以用来备份和恢复以前的配置。所有存档都保存到 /var/lib/authconfig/ 目录中的唯一子目录中。例如，-- savebackup 选项将备份目录指定为 2011-07-01 ：
[root@server ~]# authconfig --savebackup=2011-07-01
这会备份
/var/lib/authconfig/backup-2011-07-01 目录下的所有身份验证配置文件。
任何保存的备份都可用于使用
--restorebackup 选项恢复配置，给出手动保存的配置的名称：
[root@server ~]# authconfig --restorebackup=2011-07-01
另外，authconfig 会在应用任何更改前自动备份配置（使用
--update 选项）。可以使用 --restorelastbackup 选项从最新的自动备份中恢复配置，而无需指定准确的备份。
第 6 章 使用 authconfig启用自定义主目录
如果 LDAP 用户有不在
/home 中的主目录，并且系统被配置为首次登录时创建主目录，则这些目录将创建有错误的权限。
- 将
/home目录中的正确的 SELinux 上下文和权限应用到在本地系统上创建的主目录。例如：[root@server ~]# semanage fcontext -a -e /home /home/locale
- 在系统中安装
oddjob-mkhomedir软件包。这个软件包提供了pam_oddjob_mkhomedir.so库，authconfig 命令用来创建主目录。pam_oddjob_mkhomedir.so库与默认的pam_mkhomedir.so库不同，可以创建 SELinux 标签。authconfig 命令会自动使用pam_oddjob_mkhomedir.so库（如果可用）。否则，它将默认使用pam_mkhomedir.so。 - 确保
oddjobd服务正在运行。 - 运行 authconfig 命令并启用主目录。在命令行中，这通过
--enablemkhomedir选项完成。[root@server ~]# authconfig --enablemkhomedir --update
在 UI 中，在" 高级选项 "选项卡（首次登录时创建主目录）中有一个选项，可在用户第一次登录时自动创建主目录。图 6.1. 主目录选项
此选项对于集中管理的帐户很有用，例如通过 LDAP 管理。但是，如果自动挂载等系统用于管理用户主目录，则不应选择此选项。
如果在主目录配置之前创建主目录，则更正权限和 SELinux 上下文。例如：
[root@server ~]# semanage fcontext -a -e /home /home/locale # restorecon -R -v /home/locale
部分 II. 身份和身份验证存储
这部分解释了如何
配置系统安全服务守护进程 (SSSD)，如何使用 realmd 工具连接到身份域，以及如何安装、配置和运行 OpenLDAP 服务器。
第 7 章 配置 SSSD
7.1. SSSD 简介
7.1.1. SSSD 如何工作
系统安全服务守护程序(SSSD)是一种用于访问远程目录和身份验证机制的系统服务。它将本地系统（SSSD 客户端）连接到外部后端系统（ 供应商）。这为 SSSD 客户端提供了使用 SSSD 供应商访问身份和身份验证远程服务的权限。例如，这些远程服务包括：LDAP 目录、身份管理(IdM)或 Active Directory(AD)域，或者 Kerberos 域。
为此，SSSD:
- 将客户端连接到身份存储以检索身份验证信息.
- 使用获取的身份验证信息在客户端上创建用户和凭据的本地缓存。
然后，本地系统上的用户可以使用存储在外部后端系统中的用户帐户进行身份验证。
SSSD 不会在本地系统上创建用户帐户。相反，它使用外部数据存储中的身份，并允许用户访问本地系统。
图 7.1. SSSD 如何工作
SSSD 还可以为多个系统服务提供缓存，如名称服务交换机 (NSS) 或可插拔验证模块 (PAM)。
7.1.2. 使用 SSSD 的好处
- 减少身份和身份验证服务器上的负载
- 在请求信息时，SSSD 客户端会联系 SSSD，后者检查其缓存。只有在缓存中没有这些信息时，SSSD 才会联系服务器。
- 离线验证
- SSSD 可选择性地保留从远程服务检索的用户身份和凭证缓存。在这个设置中，即使远程服务器或 SSSD 客户端离线，用户也可以成功对资源进行身份验证。
- 单一用户帐户：提高身份验证过程的一致性
- 使用 SSSD 时，不需要同时维护中央帐户和本地用户帐户进行离线身份验证。远程用户通常具有多个用户帐户。例如，要连接到虚拟专用网络（VPN），远程用户需要有一个本地系统帐户，以及另外一个 VPN 帐户。由于缓存和离线身份验证，远程用户只需通过向本地计算机进行身份验证即可连接到网络资源。然后，SSSD 维护其网络凭证。
7.2. 在 Per-client Basis 中使用多个 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 目录中的隐藏文件（以 .开头的文件）。
7.3. 为 SSSD 配置身份和身份验证供应商
7.3.1. SSSD 身份和身份验证提供程序简介
SSSD 域.身份和身份验证供应商
身份和身份验证提供程序在 SSSD 配置文件中配置为 域。单个域可用作：
- 身份提供商 （用户信息）
- 身份验证提供程序 （用于身份验证请求）
- 访问控制提供程序 （用于授权请求）
- 组合这些提供程序（如果所有对应的操作都在单一服务器中执行）
您可以为 SSSD 配置多个域。必须至少配置一个域，否则 SSSD 不会启动。
/etc/sssd/sssd.conf 文件中的 access_provider 选项设置用于域的访问控制提供程序。默认情况下，选项设置为 permit，这将始终允许所有访问。详情请查看 sssd.conf(5) man page。
代理供应商
代理供应商充当 SSSD 和 SSSD 资源之间的中间中继。使用代理供应商时，SSSD 会连接到代理服务，代理会加载指定的库。
通过使用代理供应商，您可以配置 SSSD 以使用：
- 其他验证方法，如指纹扫描仪
- 传统系统，如 NIS
- 在
/etc/passwd和远程身份验证中定义的本地系统帐户
身份供应商可以和认证服务商组合使用
表 7.1. 身份供应商可以和认证服务商组合使用
请注意，本指南并不描述所有供应商类型。如需更多信息，请参阅以下其他资源：
- 要为身份管理配置 SSSD 客户端，红帽建议使用
ipa-client-install工具。请参阅《 Linux 域身份、身份验证和策略指南》中的 安装和卸载身份管理 客户端。 - 要在没有
ipa-client-install的情况下为 身份管理配置 SSSD 客户端，请参阅红帽知识库中的手动安装和卸载 身份管理客户端。 - 要配置与 SSSD 一起使用的 Active Directory，请参阅 Windows 集成指南 中的将 Active Directory 用作 SSSD 的身份提供程序。
7.3.2. 为 SSSD 配置 LDAP 域
先决条件
- 安装 SSSD.
# yum install sssd
配置 SSSD 以发现 LDAP 域
- 打开
/etc/sssd/sssd.conf文件： - 为 LDAP 域创建一个
[domain]部分：[domain/LDAP_domain_name] - 如果您要使用 LDAP 服务器作为身份提供程序、身份验证供应商或两者，请指定它们。
- 要将 LDAP 服务器用作身份提供程序，将
id_provider选项设置为ldap。 - 要将 LDAP 服务器用作身份验证供应商，请将
auth_provider选项设置为ldap。
例如，将 LDAP 服务器用作：[domain/LDAP_domain_name]
id_provider = ldapauth_provider = ldap - 指定 LDAP 服务器。选择以下任意一项：
- 要显式定义服务器，使用
ldap_uri选项指定服务器的 URI：[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap
ldap_uri = ldap://ldap.example.comldap_uri选项还接受服务器的 IP 地址。但是，使用 IP 地址而不是服务器名称可能会导致 TLS/SSL 连接失败。请参阅在红帽知识库 中的证书主题名称中配置 SSSD 提供程序以使用 IP 地址。 - 要将 SSSD 配置为使用 DNS 服务发现动态发现服务器，请参阅 第 7.4.3 节 “配置 DNS 服务发现”。
另外，还可在ldap_backup_uri选项指定备份服务器。 - 在
ldap_search_base选项指定 LDAP 服务器的搜索基础：[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com - 指定与 LDAP 服务器建立安全连接的方式。推荐的方法是使用 TLS 连接。要做到这一点，启用
ldap_id_use_start_tls选项，并使用这些与 CA 证书相关的选项：ldap_tls_reqcert指定客户端请求服务器证书以及在证书上执行哪些检查ldap_tls_cacert指定包含证书的文件
[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = trueldap_tls_reqcert = demandldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt注意SSSD 始终使用加密频道进行身份验证，这可以确保密码绝不通过网络未加密发送。使用ldap_id_use_start_tls = true时，身份查找（如基于id或getent工具的命令）也被加密。 - 将新域添加到
[sssd]部分中的domains选项中。选项列出 SSSD 查询的域。例如：domains =
LDAP_domain_name, domain2
其它资源
以上步骤显示了 LDAP 供应商的基本选项。如需了解更多详细信息，请参阅：
- sssd.conf(5) man page，它描述了适用于所有域的全局选项
- sssd-ldap(5) man page，它描述了特定于 LDAP 的选项
7.3.3. 为 SSSD 配置文件提供程序
文件 提供程序镜像 /etc/passwd 和 /etc/groups 文件的内容，以通过 SSSD 使这些文件中的用户和组可用。这可让您将 sss 数据库设置为 /etc/nsswitch.conf 文件中的用户和组的第一个源：
passwd: sss files group: sss files
使用这个设置时，如果在
/etc/sssd/sssd.conf 中配置了 文件 提供程序，Red Hat Enterprise Linux 会首先将用户和组的所有查询发送到 SSSD。如果 SSSD 没有运行，或者 SSSD 无法找到请求的条目，系统会返回在本地文件中查找用户和组。如果您将大多数用户和组存储在中央数据库中，如 LDAP 目录，则此设置会增加用户和组查找的速度。
先决条件
- 安装 SSSD.
# yum install sssd
配置 SSSD 以发现文件域
- 在
/etc/sssd/sssd.conf文件中添加以下部分：[domain/files] id_provider = files
- 另外，还可在
/etc/sssd/sssd.conf文件中将 sss 数据库设置为用户和组查找的第一个源：passwd: sss files group: sss files
- 将系统配置为在系统引导时启动
sssd服务：# systemctl enable sssd
- 重启
sssd服务：# systemctl restart sssd
其它资源
以上步骤显示了
文件 提供程序的基本选项。如需了解更多详细信息，请参阅：
- sssd.conf(5) man page，它描述了适用于所有域的全局选项
- sssd-files(5) man page，它描述了特定于
文件供应商的选项
7.3.4. 为 SSSD 配置代理提供程序
先决条件
- 安装 SSSD.
# yum install sssd
配置 SSSD 以发现代理域
- 打开
/etc/sssd/sssd.conf文件： - 为代理供应商创建一个
[domain]部分：[domain/proxy_name] - 指定身份验证供应商：
- 将
auth_provider选项设置为代理。 - 使用
proxy_pam_target选项指定 PAM 服务作为身份验证代理。
例如：[domain/proxy_name]
auth_provider = proxyproxy_pam_target = sssdpamproxy重要确保代理 PAM 堆栈 不 递归包含pam_sss.so。 - 指定身份提供程序：
- 将
id_provider选项设置为代理。 - 使用
proxy_lib_name选项指定 NSS 库作为身份代理。
例如：[domain/proxy_name]
id_provider = proxyproxy_lib_name = nis - 将新域添加到
[sssd]部分中的domains选项中。选项列出 SSSD 查询的域。例如：domains =
proxy_name, domain2
其它资源
以上步骤显示了代理供应商的基本选项。详情请查看 sssd.conf(5) man page，它描述了所有类型的域和其他代理相关的选项可用的全局选项。
7.3.5. 配置 Kerberos 身份验证供应商
先决条件
- 安装 SSSD.
# yum install sssd
配置 SSSD 以发现 Kerberos 域
- 打开
/etc/sssd/sssd.conf文件： - 为 SSSD 域创建一个
[domain]部分。[domain/Kerberos_domain_name] - 指定身份提供程序。例如，有关配置 LDAP 身份提供程序的详情，请参考 第 7.3.2 节 “为 SSSD 配置 LDAP 域”。如果指定的身份提供程序中没有 Kerberos 主体名称，SSSD 会使用格式 username@REALM 构造主体。
- 指定 Kerberos 身份验证供应商详情：
- 将
auth_provider选项设置为krb5。[domain/Kerberos_domain_name] id_provider = ldap
auth_provider = krb5 - 指定 Kerberos 服务器：
- 要显式定义服务器，使用
krb5_server选项。选项接受服务器的主机名或 IP 地址：[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5
krb5_server = kdc.example.com - 要将 SSSD 配置为使用 DNS 服务发现动态发现服务器，请参阅 第 7.4.3 节 “配置 DNS 服务发现”。
另外，还可在krb5_backup_server选项指定备份服务器。 - 如果 Change Password 服务没有在
krb5_server或krb5_backup_server中指定的 KDC 上运行，使用krb5_passwd选项指定运行该服务的服务器。[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5 krb5_server = kdc.example.com krb5_backup_server = kerberos.example.com
krb5_passwd = kerberos.admin.example.com如果没有使用krb5_passwd，SSSD 将使用krb5_server或krb5_backup_server中指定的 KDC。 - 使用
krb5_realm选项指定 Kerberos 域的名称。[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5 krb5_server = kerberos.example.com krb5_backup_server = kerberos2.example.com krb5_passwd = kerberos.admin.example.com
krb5_realm = EXAMPLE.COM
- 将新域添加到
[sssd]部分中的domains选项中。选项列出 SSSD 查询的域。例如：domains =
Kerberos_domain_name, domain2
其它资源
以上步骤显示了 Kerberos 供应商的基本选项。如需了解更多详细信息，请参阅：
- sssd.conf(5) man page，它描述了适用于所有域的全局选项
- sssd-krb5(5) man page，它描述了特定于 Kerberos 的选项
7.4. 身份和身份验证提供程序的其他配置
7.4.1. 调整用户名格式
7.4.1.1. 定义 Parsing Full User Names 的正则表达式
SSSD 将完整的用户名字符串解析到用户名和域组件中。默认情况下，SSSD 根据 Python 语法中的以下正则表达式，以
user_name@domain_name 格式解释完整的用户名：
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
注意
对于身份管理和 Active Directory 提供程序，默认用户名格式为user_name
@domain_name或 NetBIOS_name \user_name。
要调整 SSSD 如何解释完整用户名：
- 打开
/etc/sssd/sssd.conf文件： - 使用
re_expression选项定义自定义正则表达式。- 要为所有域全局定义正则表达式，请将
re_expression添加到sssd.conf的[sssd]部分。 - 要单独为特定域定义正则表达式，请将
re_expression添加到sssd.conf的对应域部分。
例如，要为 LDAP 域配置正则表达式：
[domain/LDAP]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
详情请查看
re_expression man page 的 SPECIAL SECTIONS 和 DOMAIN SECTIONS 部分中的描述。sssd.conf(5)
7.4.1.2. 定义 SSSD 如何打印完整用户名
如果在
/etc/sssd/sssd.conf 文件中启用了 use_fully_qualified_names 选项，SSSD 会默认根据以下扩展以 name@domain 格式打印完整的用户名：
%1$s@%2$s
注意
如果没有为可信域设置
use_fully_qualified_names，或者明确设置为 false，则只打印用户名，且没有域组件。
要调整 SSSD 显示完整用户名的格式：
- 打开
/etc/sssd/sssd.conf文件： - 使用
full_name_format选项定义完整用户名格式的扩展：- 要为所有域全局定义扩展，请将
full_name_format添加到sssd.conf的[sssd]部分。 - 要单独为特定域定义扩展，请将
full_name_format添加到sssd.conf的对应域部分。
详情请查看
full_name_format man page 的 SPECIAL SECTIONS 和 DOMAIN SECTIONS 部分中的描述。sssd.conf(5)
在某些名称配置中，SSSD 可能会条带名称的域组件，这会导致身份验证错误。因此，如果您将
full_name_format 设置为非标准值，系统会提示您将其改为更标准的格式。
7.4.2. 启用离线身份验证
默认情况下，SSSD 不缓存用户凭证。在处理身份验证请求时，SSSD 始终联系身份提供程序。如果提供商不可用，用户身份验证会失败。
重要
SSSD 永远不会以纯文本形式缓存密码。它仅存储密码的哈希。
要确保即使在身份提供程序不可用时用户也可以进行身份验证，启用凭证缓存：
- 打开
/etc/sssd/sssd.conf文件： - 在 domain 部分，添加
cache_credentials = true设置：[domain/domain_name]
cache_credentials = true - 可选，但推荐.为 SSSD 允许在身份提供程序不可用的情况下进行离线身份验证的时间限制。
- 配置 PAM 服务以使用 SSSD。请参阅 第 7.5.2 节 “配置服务：PAM”。
- 使用
offline_credentials_expiration选项指定时间限制。例如，指定用户自上次成功登录以来能够脱机验证 3 天：[pam]
offline_credentials_expiration = 3
有关
offline_credentials_expiration 的详情，请查看 sssd.conf(5) man page。
7.4.3. 配置 DNS 服务发现
如果没有在
/etc/sssd/sssd.conf 文件中明确定义身份或身份验证服务器，SSSD 可以使用 DNS 服务发现动态发现服务器 [1].
例如，如果
sssd.conf 包含 id_provider = ldap 设置，但 ldap_uri 选项没有指定任何主机名或 IP 地址，SSSD 会使用 DNS 服务发现来动态发现服务器。
注意
SSSD 无法动态发现备份服务器，只有主服务器。
为 DNS 服务发现配置 SSSD
- 打开
/etc/sssd/sssd.conf文件： - 将主服务器值设置为
_srv_。对于 LDAP 供应商，主服务器使用ldap_uri选项设置：[domain/domain_name] id_provider = ldap
ldap_uri = _srv_ - 设置服务类型，在密码更改供应商中启用服务发现：
[domain/domain_name] id_provider = ldap ldap_uri = _srv_
chpass_provider = ldapldap_chpass_dns_service_name = ldap - 可选。默认情况下，服务发现使用系统主机名的域部分作为域名。要使用不同的 DNS 域，在
dns_discovery_domain选项指定域名。 - 可选。默认情况下，服务发现扫描 LDAP 服务类型。要使用不同的服务类型，在
ldap_dns_service_name选项指定类型。 - 可选。默认情况下，SSSD 会尝试查找 IPv4 地址。如果尝试失败，SSSD 会尝试查找 IPv6 地址。要自定义此行为，使用
lookup_family_order选项。详情请查看 sssd.conf(5) man page。 - 对于您要使用服务发现的每个服务，在 DNS 服务器中添加 DNS 记录：
_service._protocol._domain TTL priority weight port host_name
7.4.4. 使用 简单 访问提供程序定义访问控制
simple 访问提供程序会基于用户名或组允许或拒绝访问。它可让您限制对特定机器的访问。
例如，在公司笔记本电脑中，您可以使用
简单 访问提供程序限制对特定用户或特定组的访问。即使他们针对配置的身份验证提供程序成功进行身份验证，也不允许其他用户或组登录。
配置 简单的 访问提供程序规则
- 打开
/etc/sssd/sssd.conf文件： - 将
access_provider选项设置为simple：[domain/domain_name]
access_provider = simple - 为用户定义访问控制规则。选择以下任意一项：
- 要允许用户访问用户，使用
simple_allow_users选项。 - 要拒绝对用户的访问，使用
simple_deny_users选项。重要因此，允许访问特定用户通常被认为比拒绝对特定用户的访问更安全。如果您拒绝对特定用户的访问，则会自动允许对所有其他用户的访问。
- 定义组的访问控制规则。选择以下任意一项：
- 要允许访问组，使用
simple_allow_groups选项。 - 要拒绝对组的访问，使用
simple_deny_groups选项。重要因此，允许访问特定组通常被认为比拒绝对特定组的访问更安全。如果您拒绝访问特定组，则会自动允许访问其他任何组。
以下示例允许访问
user 1、user2 和 group1 的成员，同时拒绝对所有其他用户的访问。
[domain/domain_name] access_provider = simplesimple_allow_users = user1, user2simple_allow_groups = group1
详情请查看 sssd-simple(5) man page。
7.4.5. 使用 LDAP 访问过滤器定义访问控制
当在
/etc/sssd/sssd.conf 中设置 access_provider 选项时，SSSD 会使用指定的访问提供程序来评估哪些用户被授予系统访问权限。如果您正在使用的访问提供程序是 LDAP 供应商类型的扩展，您也可以指定用户必须匹配的 LDAP 访问控制过滤器才能允许访问该系统。
例如，当使用 Active Directory(AD)服务器作为访问提供程序时，您可以将 Linux 系统的访问权限限制为指定的 AD 用户。与指定过滤器不匹配的所有其他用户将被拒绝访问。
注意
访问过滤器仅应用于 LDAP 用户条目。因此，在嵌套组上使用这种类型的访问控制可能无法正常工作。要在嵌套组中应用访问控制，请参阅 第 7.4.4 节 “使用
简单 访问提供程序定义访问控制”。
重要
使用脱机缓存时，SSSD 会检查用户最近的在线登录尝试是否成功。在最近一次在线登录期间成功登录的用户仍将能够脱机登录，即使他们与访问过滤器不匹配。
配置 SSSD 以应用 LDAP 访问过滤器
- 打开
/etc/sssd/sssd.conf文件： - 在
[domain]部分中，指定 LDAP 访问控制过滤器。- 对于 LDAP 访问供应商，使用
ldap_access_filter选项。详情请查看 sssd-ldap(5) man page。 - 对于 AD 访问供应商，使用
ad_access_filter选项。详情请查看 sssd-ad(5) man page。
例如，要只允许访问属于admins用户组并设置了unixHomeDirectory属性的 AD 用户：[domain/AD_domain_name] access provider = ad [... file truncated ...]
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
SSSD 也可以通过条目中的
authorizedService 或 host 属性检查结果。实际上，所有选项 - LDAP 过滤器、authorizedService 和 host - 可以根据用户条目和配置进行评估。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) man page 中列出了其他访问控制参数。
7.5. 为 SSSD 配置系统服务
SSSD 提供多个系统服务的接口。最值得注意的是：
- 名称服务切换(NSS)
- 请参阅 第 7.5.1 节 “配置服务：NSS”。
- 可插拔验证模块(PAM)
- 请参阅 第 7.5.2 节 “配置服务：PAM”。
- OpenSSH
autofssudo
7.5.1. 配置服务：NSS
SSSD 如何使用 NSS 工作
Name Service Switch(NSS)服务使用配置源映射系统身份和服务：它提供了一个中央配置存储，服务可在其中查找各种配置和名称解析机制的来源。
SSSD 可以使用 NSS 作为多种类型的 NSS 映射的供应商。最值得注意的是：
- 用户信息(
passwd映射) - 组(
组映射) - Netgroups (
网络组映射) - 服务(
服务映射)
先决条件
- 安装 SSSD.
# yum install sssd
配置 NSS 服务以使用 SSSD
- 使用
authconfig工具启用 SSSD：[root@server ~]# authconfig --enablesssd --update
这会更新/etc/nsswitch.conf文件，以便启用以下 NSS 映射以使用 SSSD：passwd: files sss shadow: files sss group: files sss netgroup: files sss
- 打开
/etc/nsswitch.conf并在servicesmap 行中添加sss：services: files
sss
配置 SSSD 以使用 NSS
- 打开
/etc/sssd/sssd.conf文件： - 在
[sssd]部分中，确保 NSS 列为使用 SSSD 的服务之一。[sssd] [... file truncated ...] services =
nss, pam - 在
[nss]部分中，配置 SSSD 如何与 NSS 交互。例如：[nss] filter_groups = root filter_users = root entry_cache_timeout = 300 entry_cache_nowait_percentage = 75
有关可用选项的完整列表，请查看 sssd.conf(5) man page 中的NSS 配置选项。 - 重启 SSSD。
# systemctl restart sssd.service
测试 Integration Works 是否正确
使用以下命令显示用户的信息：
- ID 用户
- passwd passwd 用户
7.5.2. 配置服务：PAM
警告
PAM 配置文件中的错误可以完全将用户锁定在系统之外。始终在执行任何更改前备份配置文件，并保持会话打开，以便您可以恢复任何更改。
配置 PAM 使用 SSSD
- 使用
authconfig工具启用 SSSD：# authconfig --enablesssdauth --update
这会更新 PAM 配置来引用 SSSD 模块，通常位于/etc/pam.d/system-auth和/etc/pam.d/password-auth文件中。例如：[... file truncated ...] auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so [... file truncated ...]
详情请查看 pam.conf(5) 或 pam(8) man page。
配置 SSSD 以使用 PAM
- 打开
/etc/sssd/sssd.conf文件： - 在
[sssd]部分中，确保 PAM 列为使用 SSSD 的服务之一。[sssd] [... file truncated ...] services = nss,
pam - 在
[pam]部分中，配置 SSSD 如何与 PAM 交互。例如：[pam] offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5
有关可用选项的完整列表，请参阅 sssd.conf(5) man page 中的PAM 配置选项。 - 重启 SSSD。
# systemctl restart sssd.service
测试 Integration Works 是否正确
- 尝试以某一用户身份登录。
- 使用 sssctl user-checks user_name auth 命令检查 SSSD 配置。详情请查看 sssctl user-checks --help 命令。
7.5.3. 配置服务： autofs
具有 自动挂载的SSSD 工作方式
您可以将
automount 配置为指向 SSSD。在这个设置中：
- 当用户尝试挂载目录时，SSSD 会联系 LDAP 来获取当前
自动挂载配置所需的信息。 - SSSD 将
自动挂载所需的信息存储在缓存中，因此即使 LDAP 服务器离线，用户可以挂载目录。
将 autofs 配置为使用 SSSD
- 安装 autofs 软件包。
# yum install autofs
- 打开
/etc/nsswitch.conf文件。 - 在
automount行中，将从 ldap 中查找自动挂载映射信息的位置从ldap改为sss：automount: files
sss
配置 SSSD 以使用 autofs
- 打开
/etc/sssd/sssd.conf文件： - 在
[sssd]部分中，将autofs添加到 SSSD 管理的服务列表中。[sssd] services = nss,pam,
autofs - 创建一个新的
[autofs]部分。您可以将它留空。[autofs]有关可用选项列表，请参阅 sssd.conf(5) man page 中的AUTOFS 配置选项。 sssd.conf的[domain]部分接受几个与autofs相关的选项。例如：[domain/LDAP] [... file truncated ...]
autofs_provider=ldapldap_autofs_search_base=cn=automount,dc=example,dc=comldap_autofs_map_object_class=automountMapldap_autofs_entry_object_class=automountldap_autofs_map_name=automountMapNameldap_autofs_entry_key=automountKeyldap_autofs_entry_value=automountInformation有关可用选项的完整列表，请参阅 sssd.conf(5) man page 中的DOMAIN SECTIONS。如果没有提供其他autofs选项，则配置取决于身份提供程序设置。- 重启 SSSD。
# systemctl restart sssd.service
测试配置
- 使用 automount -m 命令打印来自 SSSD 的映射。
7.5.4. 配置服务： sudo
使用 sudo的 SSSD 工作方式
您可以将
sudo 配置为指向 SSSD。在这个设置中：
- 当用户尝试
sudo操作时，SSSD 会联系 LDAP 或 AD 来获取当前sudo配置所需的信息。 - SSSD 将
sudo信息存储在缓存中，因此即使 LDAP 或 AD 服务器离线，用户可以执行sudo操作。
SSSD 仅缓存应用于本地系统的
sudo 规则，具体取决于 sudoHost 属性的值。详情请查看 sssd-sudo(5) man page。
将 sudo 配置为使用 SSSD
- 打开
/etc/nsswitch.conf文件。 - 将 SSSD 添加到
sudoers行上的列表中。sudoers: files
sss
配置 SSSD 以使用 sudo
- 打开
/etc/sssd/sssd.conf文件： - 在
[sssd]部分中，将sudo添加到 SSSD 管理的服务列表中。[sssd] services = nss,pam,
sudo - 创建一个新的
[sudo]部分。您可以将它留空。[sudo]有关可用选项列表，请参阅 sssd.conf(5) man page 中的SUDO 配置选项。 - 确保
sssd.conf中有 LDAP 或 AD 域，以便 SSSD 可以从 目录读取sudo信息。详情请查看：- Windows 集成指南 中的 将 Active Directory 用作 SSSD 身份提供商 一节.
LDAP 或 AD 域的[domain]部分必须包含这些与sudo相关的参数：[domain/LDAP_or_AD_domain] ...
sudo_provider = ldapldap_sudo_search_base = ou=sudoers,dc=example,dc=com注意将身份管理或 AD 设置为 ID 提供程序会自动启用sudo供应商。在这种情况下，不需要指定sudo_provider参数。有关可用选项的完整列表，请参阅 sssd.conf(5) man page 中的DOMAIN SECTIONS。有关sudo供应商可用选项，请查看 sssd-ldap(5) man page。 - 重启 SSSD。
# systemctl restart sssd.service
如果使用 AD 作为供应商，您必须扩展 AD 模式来支持
sudo 规则。详情请查看 sudo 文档。
有关在 LDAP 或 AD 中提供
sudo 规则的详情，请查看 sudoers.ldap(5) man page。
7.6. SSSD 客户端视图
SSSD 允许您创建一个客户端视图来为 POSIX 用户或组属性指定新值。视图仅对配置了覆盖的本地计算机生效。您可以为除
ipa 以外的所有 id_provider 值配置客户端覆盖。如果您使用 ipa 供应商，请在 IdM 中集中定义 ID 视图。请参阅《 Linux 域身份、身份验证和策略指南》 中的对应部分。
如需更多信息，请参阅 Linux 域身份、身份验证和策略指南 中的对 SSSD 性能的影响 部分。
注意
使用 sss_override user-add、sss_override group-add 或 sss_override user-import 命令创建第一次覆盖后，重启 SSSD 以使更改生效：
# systemctl restart sssd
7.6.1. 为用户帐户定义不同的属性值
作为管理员，您要将现有主机配置为使用 LDAP 中的帐户。但是，LDAP 中的用户新 ID 与本地系统上的用户之前 ID 不同。您可以配置客户端侧视图来覆盖 UID，而不是更改现有文件的权限。
使用 UID 6666 覆盖用户帐户 的 UID：
- 可选。显示 用户帐户 的当前 UID：
# id user uid=1241400014(user_name) gid=1241400014(user_name) Groups=1241400014(user_name) - 使用 6666 覆盖帐户的 UID：
# sss_override user-add user -u 6666
- 等待内存中缓存过期。手动过期：
# sss_cache --users
- 验证是否应用了新的 UID：
# id user uid=6666(user_name) gid=1241400014(user_name) Groups=1241400014(user_name) - 可选。显示用户的覆盖：
# sss_override user-show user user@ldap.example.com::6666:::::
如需您可以覆盖的属性列表，请在命令中添加
--help 来列出命令行选项：
# sss_override user-add --help
7.6.2. 列出主机上的所有覆盖
作为管理员，您要列出主机上的所有用户和组覆盖，以验证是否已覆盖正确的属性。
列出所有用户覆盖：
# 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 ...
7.6.3. 删除本地覆盖
您之前为 用户帐户 的 shell 创建覆盖，该帐户在全局 LDAP 目录中定义。要删除帐户的覆盖，请运行：
# sss_override user-del user
更改会立即生效。
要为组群删除覆盖，请运行：
# sss_override group-del group
注意
当您为用户或组群删除覆盖时，此对象的所有覆盖都会被删除。
7.6.4. 导出和导入本地视图
客户端视图存储在本地 SSSD 缓存中。您可以将用户和组视图从缓存导出到文件，以创建备份。例如，当删除 SSSD 缓存时，您可以稍后重新恢复视图。
备份用户和组视图：
# 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
7.7. 降级 SSSD
当降级 - 降级 SSSD 版本或降级操作系统本身时，需要移除现有的 SSSD 缓存。如果没有删除缓存，则 SSSD 进程已死机，但 PID 文件仍然存在。SSSD 日志显示它无法连接到任何关联的域，因为缓存版本没有被识别。
(Wed Nov 28 21:25:50 2012) [sssd] [sysdb_domain_init_internal] (0x0010): Unknown DB version [0.14], expected [0.10] for domain AD!
然后，用户不再被识别，无法向域服务和主机进行身份验证。
降级 SSSD 版本后：
- 删除现有的缓存数据库文件。
[root@server ~]# rm -rf /var/lib/sss/db/*
- 重启 SSSD 进程。
[root@server ~]# systemctl restart sssd.service
7.8. 将 NSCD 与 SSSD 搭配使用
SSSD 的设计不是与 NSCD 守护进程一起使用。尽管 SSSD 不直接与 NSCD 冲突，但使用这两个服务可能会导致意外行为，特别是缓存条目的时间。
问题的最常见证明是与 NFS 冲突。使用网络管理器管理网络连接时，可能需要几分钟时间来启动网络接口。在该时间内，各种服务尝试启动。如果在网络启动前启动这些服务并且 DNS 服务器可用，这些服务将无法识别它们所需的正向或反向 DNS 条目。这些服务将读取不正确的或可能空的
resolv.conf 文件。通常仅读取一次此文件，因此不会自动应用对该文件所做的任何更改。这可能会导致在运行 NSCD 服务的机器上 NFS 锁定失败，除非手动重启该服务。
要避免这个问题，请只对
/etc/nscd.conf 文件中的 主机 启用缓存，并依赖 passwd、组、services 和 netgroup 条目的 SSSD 缓存。
更改
/etc/nscd.conf 文件：
enable-cache hosts yes enable-cache passwd no enable-cache group no enable-cache netgroup no enable-cache services no
使用 NSCD 应答主机请求，这些条目将由 NSCD 缓存，并在引导过程中由 NSCD 返回。所有其他条目都由 SSSD 处理。
7.9. 其它资源
- sssd(8) man page 中的
SEE ALSO部分中提供了与 SSSD 相关的 man page 的完整列表。 - 故障排除建议： 第 A.1 节 “SSSD 故障排除”.
- 配置 SSSD 以处理服务器发送的密码过期警告并将其显示到本地系统中的用户的步骤：在红帽知识库 中设置密码过期 警告
- SSSD 客户端可以为从 LDAP 服务器检索的每个用户自动创建一个 GID，同时确保 GID 与用户的 UID 匹配，除非已经获取了 GID 号。要查看如何在直接集成到 Active Directory 的 SSSD 客户端上设置自动创建 GID，请参阅 Windows 集成指南中 的对应部分。
第 8 章 使用 realmd 连接到身份域
realmd 系统提供了一种清晰、简单的方法来发现和加入身份域。它不连接到域本身，而是配置底层 Linux 系统服务（如 SSSD 或 Winbind）以连接到该域。
Windows 集成指南 描述了使用
realmd 连接到 Microsoft Active Directory (AD)域。相同的流程适用于使用 realmd 连接到非 AD 身份域。请参阅《 Windows 集成指南 》中的使用域 连接到 Active Directory 域。
第 9 章 LDAP 服务器
LDAP （轻量级目录访问协议）是一组开放协议，用于通过网络访问集中存储的信息。它基于用于目录共享的 X.500 标准，但不太复杂和资源密集型。因此，LDAP 有时称为 “X.500 Lite”。
与 X.500 一样，LDAP 使用目录以分层方式组织信息。这些目录可以存储各种信息，如名称、地址或电话号码，甚至可以使用类似于 网络信息服务( NIS)的方式，使任何人都能够从 LDAP 启用网络网络上的任何计算机访问其帐户。
LDAP 通常用于集中管理的用户和组、用户身份验证或系统配置。它还可以作为虚拟电话目录，允许用户轻松访问其他用户的联系信息。此外，它也可将用户引用全球范围内的其他 LDAP 服务器，从而提供一个临时的全球信息存储库。但是，它最常用于个别组织，如大学、政府机构和私人公司。
9.1. Red Hat Directory Server
红帽目录服务器是 LDAP 兼容服务器，可集中管理用户身份和应用程序信息。它提供独立于操作系统和网络的注册表，用于存储应用程序设置、用户配置文件、组数据、策略和访问控制信息。
注意
您需要订阅最新的红帽目录服务器来安装和更新目录服务器。
有关设置和使用目录服务器的详情，请参考：
9.2. OpenLDAP
本节介绍 OpenLDAP 2.4 的安装和配置，这是 LDAPv2 和 LDAPv3 协议的开源实现。
注意
从 Red Hat Enterprise Linux 7.4 开始，openldap-server 软件包已弃用，并将不包含在 Red Hat Enterprise Linux 未来的主发行版本中。因此，迁移到红帽企业 Linux 中包含的身份管理或红帽目录服务器。有关身份管理的详情，请参阅 Linux 域身份、身份验证和策略指南。有关目录服务器的详情请参考 第 9.1 节 “Red Hat Directory Server”。
9.2.1. LDAP 简介
通过使用客户端-服务器架构，LDAP 提供了一种可靠的方法来创建可从网络访问的中央信息目录。当客户端尝试修改此目录中的信息时，服务器验证用户是否有权进行更改，然后根据请求添加或更新条目。为确保通信安全，可使用 传输层安全 (TLS)加密协议来防止攻击者拦截传输。
重要
Red Hat Enterprise Linux 7.5 及更高版本中的 OpenLDAP 套件不再使用网络安全 服务 (NSS)的 Mozilla 实施。而是使用 OpenSSL。OpenLDAP 继续使用现有的 NSS 数据库配置。
重要
由于 Resolution for POODLE SSLv3.0 漏洞(CVE-2014-3566)中描述的漏洞，对于不允许通过配置设置禁用 SSLv3 的组件，红帽建议您不依赖
SSLv3 协议进行安全。OpenLDAP 是系统组件之一，不提供允许有效禁用 SSLv3 的配置参数。要降低风险，建议您使用 stunnel 命令提供安全隧道，并使用 SSLv3 禁用 stunnel。有关使用 stunnel 的更多信息，请参阅 Red Hat Enterprise Linux 7 安全指南。
LDAP 服务器支持多个数据库系统，这使管理员能够灵活地为计划服务的信息类型选择合适的解决方案。由于定义良好的客户端 应用程序编程接口( API)，能够与 LDAP 服务器通信的应用程序数量很多，且在数量和质量上不断增加。
9.2.1.1. LDAP 术语
以下是本章中使用的特定于 LDAP 的术语列表：
- 条目
- LDAP 目录中的单一单元。每个条目通过其唯一的可 辨识名称( DN)标识。
- attribute
- 与条目直接关联的信息。例如，如果组织表示为 LDAP 条目，与此组织相关联的属性可能包括地址、传真编号等。同样，人们也可以作为具有共同属性（如个人电话号码或电子邮件地址）的条目来表示。属性可以具有单个值，或者具有无顺序的空格分隔的值列表。尽管某些属性是可选的，但其他属性是必需的。必要属性使用 iwl 定义来指定，并可在位于
/etc/openldap/slapd.d/cn=config/cn=schema/目录中的 schema 文件中找到。属性的断言及其对应的值也称为 Relative Distinguished Name( RDN)。与全局唯一的可分辨名称不同，相对区分名称仅在每个条目中唯一。 - LDIF
- LDAP 数据交换格式 (LDIF)是 LDAP 条目的纯文本表示形式。它采用以下形式：
[id] dn: distinguished_name attribute_type: attribute_value… attribute_type: attribute_value… …可选的 id 是由应用决定的数字，用于编辑该条目。每个条目可以根据需要包含任意 数量的 attribute_type 和 attribute_value 对，只要它们都在对应的架构文件中定义。空白行表示条目的结尾。
9.2.1.2. OpenLDAP 功能
OpenLDAP 套件提供许多重要功能：
- LDAPv3 支持 - LDAP 版本 2 以来协议的许多更改都旨在提高 LDAP 的安全性。除了其他改进外，这还包括对简单身份验证和安全层(SASL)、传输层安全性(TLS)以及安全套接字层(SSL)协议的支持。
- LDAP Over IPC - 使用进程间通信(IPC)通过无需通过网络进行通信来提高安全性。
- IPv6 支持 - OpenLDAP 与下一代 Internet 协议版本 6(IPv6)兼容。
- LDIFv1 支持 - OpenLDAP 与 LDIF 版本 1 完全兼容。
- 更新了 C API - 当前的 C API 改进了程序员连接和使用 LDAP 目录服务器的方式。
- 增强的单机 LDAP 服务器 - 包括更新的访问权限控制系统、线程池、更好的工具等。
9.2.1.3. OpenLDAP 服务器设置
在 Red Hat Enterprise Linux 中设置 LDAP 服务器的典型步骤如下：
- 安装 OpenLDAP 套件。有关所需软件包的更多信息，请参阅 第 9.2.2 节 “安装 OpenLDAP 套件”。
- 自定义配置，如 第 9.2.3 节 “配置 OpenLDAP 服务器” 所述。
- 按照 第 9.2.5 节 “运行 OpenLDAP 服务器” 所述启动
slapd服务。 - 使用 ldapadd 实用程序向 LDAP 目录添加条目。
- 使用 ldapsearch 工具验证
slapd服务是否正确访问信息。
9.2.2. 安装 OpenLDAP 套件
OpenLDAP 库和工具套件由以下软件包提供：
表 9.1. OpenLDAP 软件包列表
| 软件包 | Description |
|---|---|
| openldap | 包含运行 OpenLDAP 服务器和客户端应用程序所需的库的软件包。 |
| openldap-clients | 包含用于查看和修改 LDAP 服务器上的目录的命令行实用程序的软件包。 |
| openldap-servers | 包含用于配置和运行 LDAP 服务器的服务和实用程序的软件包。这包括 独立 LDAP 守护进程 slapd。 |
| compat-openldap | 包含 OpenLDAP 兼容性库的软件包。 |
另外，以下软件包通常与 LDAP 服务器一同使用：
表 9.2. 经常安装的其他 LDAP 软件包列表
| 软件包 | Description |
|---|---|
| nss-pam-ldapd | 包含 nslcd 的软件包，一个本地 LDAP 名称服务，允许用户执行本地 LDAP 查询。 |
| mod_ldap |
包含
mod_authnz_ldap 和 mod_ldap 模块的软件包。mod_authnz_ldap 模块是 Apache HTTP 服务器的 LDAP 授权模块。此模块可以针对 LDAP 目录验证用户的凭据，并且可以根据用户名、完整 DN、组成员资格、任意属性或完整的过滤器字符串强制实施访问控制。同一软件包中包含的 mod_ldap 模块提供了可配置的共享内存缓存，以避免在多个 HTTP 请求间重复目录访问，并支持 SSL/TLS。请注意，这个软件包由可选频道提供。有关红帽其他频道的更多信息，请参阅《 系统管理员指南》 中添加 Optional 和 Supplementary 存储库。
|
要安装这些软件包，请使用以下格式的 yum 命令：
yum install package…
例如，要执行基本 LDAP 服务器安装，在 shell 提示符后输入以下内容：
~]# yum install openldap openldap-clients openldap-servers
请注意，您必须具有超级用户权限（即，您必须以
root身份登录），才能运行此命令。有关如何在 Red Hat Enterprise Linux 中安装新软件包的更多信息，请参阅系统管理员 指南中的 安装软件包。
9.2.2.1. OpenLDAP 服务器实用程序概述
要执行管理任务，openldap-servers 软件包会安装以下工具以及
slapd 服务：
表 9.3. OpenLDAP 服务器实用程序列表
| 命令 | Description |
|---|---|
| slapacl | 允许您检查对属性列表的访问权限。 |
| slapadd | 允许您将 LDIF 文件中的条目添加到 LDAP 目录。 |
| slapauth | 允许您检查 ID 的列表以获得身份验证和授权权限。 |
| slapcat | 允许您以默认格式从 LDAP 目录中拉取条目，并将它们保存在 LDIF 文件中。 |
| slapdn | 允许您根据可用的架构语法检查可辨识名称(DN)的列表。 |
| slapindex | 允许您根据当前内容重新索引 slapd 目录。每当您在配置文件中更改索引选项时，运行此实用程序。 |
| slappasswd | 允许您创建用于 ldapmodify 工具或 slapd 配置文件中的加密用户密码。 |
| slapschema | 允许您使用对应的架构检查数据库合规性。 |
| slaptest | 允许您检查 LDAP 服务器配置。 |
有关这些实用程序及其用法的详细描述，请查看 “安装的文档”一节 中所述的相应 man page。
重要
虽然只有
root 用户可以运行 slapadd，但 slapd 服务以 ldap 用户身份运行。因此，目录服务器无法修改由 slapadd 创建的任何文件。要更正这个问题，在运行 slapdadd 工具后，在 shell 提示符下输入以下内容：
~]# chown -R ldap:ldap /var/lib/ldap警告
要保留数据完整性，请在使用 slapadd、slapcat 或 slapindex 之前停止
slapd 服务。您可以通过在 shell 提示符后输入以下内容来完成此操作：
~]# systemctl stop slapd.service
有关如何启动、停止、重启和检查
slapd 服务的当前状态的更多信息，请参阅 第 9.2.5 节 “运行 OpenLDAP 服务器”。
9.2.2.2. OpenLDAP 客户端实用程序概述
openldap-clients 软件包安装以下工具，可用于在 LDAP 目录中添加、修改和删除条目：
表 9.4. OpenLDAP 客户端实用程序列表
| 命令 | Description |
|---|---|
| ldapadd | 允许您从文件或标准输入向 LDAP 目录添加条目。它是 ldapmodify -a 的符号链接。 |
| ldapcompare | 允许您将给定属性与 LDAP 目录条目进行比较。 |
| ldapdelete | 允许您从 LDAP 目录删除条目。 |
| ldapexop | 允许您执行扩展的 LDAP 操作。 |
| ldapmodify | 允许您从文件或标准输入修改 LDAP 目录中的条目。 |
| ldapmodrdn | 允许修改 LDAP 目录条目的 RDN 值。 |
| ldappasswd | 允许您设置或更改 LDAP 用户的密码。 |
| ldapsearch | 允许搜索 LDAP 目录条目。 |
| ldapurl | 允许您编写或取消编译 LDAP URL。 |
| ldapwhoami | 允许您在 LDAP 服务器上执行 whoami 操作。 |
除 ldapsearch 外，通过引用包含要进行的更改的文件来更轻松地使用这些工具，而不是为每个条目输入命令以在 LDAP 目录中更改。每个实用程序的 man page 中概述了此类文件的格式。
9.2.2.3. 通用 LDAP 客户端应用程序概述
尽管有多个图形 LDAP 客户端能够在服务器上创建和修改目录，但 Red Hat Enterprise Linux 中不包含这些客户端。可在只读模式下访问目录的常用应用程序包括 Mozilla Thunderbird、Evolution、Evolution 或 Ekiga。
9.2.3. 配置 OpenLDAP 服务器
默认情况下，OpenLDAP 配置存储在
/etc/openldap/ 目录中。下表重点介绍了这个目录中最重要的目录和文件：
表 9.5. OpenLDAP 配置文件和目录列表
请注意，OpenLDAP 不再从
/etc/openldap/slapd.conf 文件中读取其配置。相反，它使用位于 /etc/openldap/slapd.d/ 目录中的配置数据库。如果您从之前安装中有一个已存在的 slapd.conf 文件，您可以运行以下命令将其转换为新格式：
~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/slapd 配置由按分级目录结构组织的 LDIF 条目组成，推荐的编辑这些条目是使用 第 9.2.2.1 节 “OpenLDAP 服务器实用程序概述” 中描述的服务器工具。
重要
LDIF 文件中的错误可能会导致
slapd 服务无法启动。因此，强烈建议您直接编辑 /etc/openldap/slapd.d/ 中的 LDIF 文件。
9.2.3.1. 更改全局配置
LDAP 服务器的全局配置选项存储在
/etc/openldap/slapd.d/cn=config.ldif 文件中。常用的指令如下：
-
olcAllows - The
olcAllows指令允许您指定要启用的功能。它采用以下形式：olcAllows: feature…它接受空格分隔的功能列表，如 表 9.6 “AvailableolcAllows选项” 所述。默认选项为bind_v2。表 9.6. Available
olcAllows选项选项 Description bind_v2启用接受 LDAP 版本 2 绑定请求。 bind_anon_cred当可辨识的名称(DN)为空时，启用匿名绑定。 bind_anon_dn当可辨识名称(DN) 不 为空时启用匿名绑定。 update_anon启用匿名更新操作的处理。 proxy_authz_anon启用匿名代理授权控制的处理。 例 9.1. 使用 the
olcAllows指令olcAllows: bind_v2 update_anon
-
olcConnMaxPending - The
olcConnMaxPending指令允许您指定匿名会话的最大待处理请求数。它采用以下形式：olcConnMaxPending: number默认选项为100。例 9.2. 使用
olcConnMaxPending指令olcConnMaxPending: 100
-
olcConnMaxPendingAuth - The
olcConnMaxPendingAuth指令允许您指定通过身份验证的会话的最大待处理请求数。它采用以下形式：olcConnMaxPendingAuth: number默认选项为1000。例 9.3. 使用 the
olcConnMaxPendingAuth指令olcConnMaxPendingAuth: 1000
-
olcDisallows - The
olcDisallows指令允许您指定禁用哪些功能。它采用以下形式：olcDisallows: feature…它接受空格分隔的功能列表，如 表 9.7 “AvailableolcDis 允许选项” 所述。默认情况下不禁用任何功能。表 9.7. Available
olcDis 允许选项选项 Description bind_anon禁用接受匿名绑定请求。 bind_simple禁用简单的绑定身份验证机制。 tls_2_anon在收到 STARTTLS 命令时禁用匿名会话强制。 tls_authc在通过身份验证时不允许 STARTTLS 命令。 例 9.4. 使用 the
olcDisallows指令olcDisallows: bind_anon
-
olcIdleTimeout - The
olcIdleTimeout指令允许您指定在关闭空闲连接前要等待的秒数。它采用以下形式：olcIdleTimeout: number默认禁用这个选项（即，设置为0）。例 9.5. 使用
olcIdleTimeout指令olcIdleTimeout: 180
-
olcLogFile - The
olcLogFile指令允许您指定要在其中写入日志消息的文件。它采用以下形式：olcLogFile: file_name默认情况下，日志消息写入标准错误。例 9.6. 使用 the
olcLogFile指令olcLogFile: /var/log/slapd.log
-
olcReferral - The
olcReferral选项允许您指定服务器的 URL，以便在服务器无法处理请求时处理请求。它采用以下形式：olcReferral: URL默认禁用这个选项。例 9.7. 使用 the
olcReferral指令olcReferral: ldap://root.openldap.org
-
olcWriteTimeout - The
olcWriteTimeout选项允许您指定在关闭与未完成的写入请求的连接之前要等待的秒数。它采用以下形式：olcWriteTimeout默认禁用这个选项（即，设置为0）。例 9.8. 使用 the
olcWriteTimeout指令olcWriteTimeout: 180
9.2.3.2. Front End 配置
OpenLDAP 前端配置存储在
etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif 文件中，并定义全局数据库选项，如访问控制列表(ACL)。详情请查看 Global Database Options man page 中的 slapd-config(5) 部分。
9.2.3.3. monitor 后端
/etc/openldap/slapd.d/cn=config/olcDatabase= availabilitymonitor.ldif 文件控制 OpenLDAP 监控后端。如果启用，它将由 OpenLDAP 自动生成并动态更新，包含有关后台程序运行状态的信息。后缀为 cn=Monitor，无法更改。详情请查看 slapd-monitor(5) man page。
9.2.3.4. 数据库特定配置
默认情况下，OpenLDAP 服务器使用
hdb 数据库后端。除了使用支持子树重命名的层次结构数据库布局外，它与 bdb 后端相同，并使用相同的配置选项。此数据库后端的配置存储在 /etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif 文件中。
有关其它后端数据库列表，请查看 slapd.backends(5) man page。您在单独后端的 man page 中找到的特定于数据库的设置。例如：
# man slapd-hdb
注意
bdb 和 hdb 后端已弃用。考虑将 mdb 后端用于新安装。
以下指令通常用于特定于数据库的配置：
-
olcReadOnly - The
olcReadOnly指令允许您以只读模式使用数据库。它采用以下形式：olcReadOnly: boolean它接受TRUE（启用只读模式）或FALSE（启用对数据库的修改）。默认选项为FALSE。例 9.9. 使用 the
olcReadOnly指令olcReadOnly: TRUE
-
olcRootDN - The
olcRootDN指令允许您指定为 LDAP 目录上操作设置的访问控制或管理限制参数不受限制的用户。它采用以下形式：olcRootDN: distinguished_name它接受可 辨识的名称( DN)。默认选项为cn=Manager,dn=my-domain,dc=com。例 9.10. 使用
olcRootDN指令olcRootDN: cn=root,dn=example,dn=com
-
olcRootPW - The
olcRootPW指令允许您为使用 aolcRootDN指令指定的用户设置密码。它采用以下形式：olcRootPW: password它接受纯文本字符串或散列。要生成哈希，在 shell 提示符后输入以下内容：~]$ slappaswd New password: Re-enter new password: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD例 9.11. 使用 the
olcRootPW指令olcRootPW: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD -
olcSuffix - The
olcSuffix指令允许您指定要提供信息的域。它采用以下形式：olcSuffix: domain_name它接受 完全限定域名( FQDN)。默认选项为dc=my-domain,dc=com。例 9.12. 使用 the
olcSuffix指令olcSuffix: dc=example,dc=com
9.2.3.5. 扩展架构
从 OpenLDAP 2.3 开始，
/etc/openldap/slapd.d/ 目录还包含之前位于 /etc/openldap/schema/ 中的 LDAP 定义。可以使用默认架构文件作为指南，扩展 OpenLDAP 使用的架构来支持附加属性类型和对象类。但是，此任务已超出本章的讨论范畴。有关此主题的更多信息，请参阅 https://openldap.org/doc/admin24/schema.html.
9.2.3.6. 建立安全连接
OpenLDAP 套件和服务器可以使用传输层安全(TLS)框架进行保护。TLS 是一种加密协议，旨在通过网络提供通信安全性。红帽企业 Linux 7 中的 OpenLDAP 套件使用 OpenSSL 作为 TLS 实施。
要使用 TLS 建立安全连接，请获取所需的证书。然后，必须在客户端和服务器上配置多个选项。至少，服务器必须配置有证书颁发机构(CA)证书，以及它自己的服务器证书和私钥。客户端必须配置包含所有可信 CA 证书的文件名称。
通常，服务器只需要为单个 CA 证书签名。客户端可能希望连接到各种安全服务器，因此在其配置中通常指定多个受信任 CA 的列表。
服务器配置
本节列出了需要在 OpenLDAP 服务器上的
/etc/openldap/ slapd.d/cn=config.ldif 文件中指定的 slapd 的全局配置指令，以建立 TLS。
虽然旧风格配置使用单个文件，但通常作为
/usr/local/etc/openldap/slapd.conf 安装，但新样式使用 slapd 后端数据库来存储配置。配置数据库通常位于 /usr/local/etc/openldap/slapd.d/ 目录中。
以下指令对建立 SSL 也有效：除了 TLS 指令外，您需要在服务器端启用专用于 SSL 的端口 - 通常为端口 636。为此，请编辑
/etc/sysconfig/slapd 文件，并将 ldaps:/// 字符串附加到通过 SLAPD_URLS 指令指定的 URL 列表中。
-
olcTLSCACertificateFile - The
olcTLSCACertificateFile指令指定包含可信 CA 证书的文件增强型邮件(PEM)模式。该指令采用以下形式：olcTLSCACertificateFile: path使用 CA 证书文件的路径替换 path。 -
olcTLSCACertificatePath - The
olcTLSCACertificatePath指令指定在独立文件中包含独立 CA 证书的目录的路径。此目录必须特别使用 OpenSSL c_rehash 程序管理，该实用程序生成指向实际证书文件的散列名称的符号链接。通常，使用 theolcTLSCACertificateFile指令更为简单。该指令采用以下形式：olcTLSCACertificatePath: path使用包含 CA 证书文件的目录的路径替换 path。指定的目录必须使用 OpenSSL c_rehash 工具进行管理。 -
olcTLSCertificateFile olcTLSCertificateFile指令指定包含slapd服务器证书的文件。该指令采用以下形式：olcTLSCertificateFile: path使用slapd服务的服务器证书文件的路径替换 path。-
olcTLSCertificateKeyFile - The
olcTLSCertificateKeyFile指令指定包含与使用olcTLSCertificateFile指定的文件中存储的证书匹配的文件。请注意，当前实施不支持加密私钥，因此必须对包含的文件进行足够的保护。该指令采用以下形式：olcTLSCertificateKeyFile: path使用私钥文件的路径替换 path。
客户端配置
在客户端系统的
/etc/openldap/ldap.conf 配置文件中指定以下指令。大多数指令与服务器配置选项并行。/etc/openldap/ldap.conf 中的指令是根据系统范围配置的，但单个用户可能会在其 ~/.ldaprc 文件中覆盖它们。
相同的指令可用于建立 SSL 连接。在 OpenLDAP 命令中，必须使用
ldaps:// 字符串而不是 ldap://。这会强制 命令对服务器上配置的 SSL（端口 636）使用默认端口。
-
TLS_CACERT TLS_CACERT指令指定包含客户端要识别的所有证书颁发机构的证书的文件。这等同于服务器上的olcTLSCACertificateFile指令。TLS_CACERT应始终在/etc/openldap/ldap.conf中的TLS_CACERTDIR之前指定。该指令采用以下形式：TLS_CACERTpath使用 CA 证书文件的路径替换 path。-
TLS_CACERTDIR TLS_CACERTDIR指令指定在单独的文件中包含证书颁发机构证书的目录的路径。与服务器上的olcTLSCACertificatePath一样，指定的目录必须使用 OpenSSL c_rehash 程序进行管理。TLS_CACERTDIRdirectory使用包含 CA 证书文件的目录的路径替换 directory。-
TLS_CERT TLS_CERT指定包含客户端证书的文件。这个指令只能在用户的~/.ldaprc文件中指定。该指令采用以下形式：TLS_CERTpath使用客户端证书文件的路径替换 path。-
TLS_KEY TLS_KEY指定包含私钥的文件，该文件与使用TLS_CERT指令指定的文件中存储的证书匹配。与服务器上的 witholcTLSCertificateFile一样，不支持加密的密钥文件，因此必须仔细保护文件本身。这个选项只能在用户的~/.ldaprc文件中进行配置。TLS_KEY指令采用以下格式：TLS_KEYpath使用客户端证书文件的路径替换 path。
9.2.3.7. 设置复制
复制是指将更新从一个 LDAP 服务器（提供商）复制到一个或多个其他服务器或客户端（使用者）的过程。提供程序向使用者复制目录更新，接收的更新可由使用者进一步传播到其他服务器，因此使用者也可以同时充当提供程序。此外，使用者不必是 LDAP 服务器，它可能只是 LDAP 客户端。在 OpenLDAP 中，您可以使用多种复制模式，最显著的是 镜像 和 同步。如需有关 OpenLDAP 复制模式的更多信息，请参阅 OpenLDAP 软件管理员指南的 openldap-servers 软件包（请参阅 “安装的文档”一节）。
要启用所选复制模式，请在供应商和消费者上使用
/etc/openldap/slapd.d/ 中的以下指令之一。
-
olcMirrorMode - The
olcMirrorMode指令启用镜像复制模式。它采用以下形式：olcMirrorModeon这个选项需要在供应商和消费者上指定。此外，还必须指定serverID和syncrepl选项。在 18.3.4 中查找详细示例。MirrorMode OpenLDAP 软件管理员指南 一节（请参阅 “安装的文档”一节）。 -
olcSyncrepl - The
olcSyncrepl指令启用同步复制模式。它采用以下形式：olcSyncreplon同步复制模式需要提供程序和使用者具有特定的配置。这个配置在 18.3.1 中进行了全面描述。OpenLDAP 软件管理员指南 中的 Syncrepl 部分（请参阅 “安装的文档”一节）。
9.2.3.8. 加载模块和后端
您可以使用动态加载的模块增强
slapd 服务。在配置 slapd 时，必须使用 --enable-modules 选项启用这些模块的支持。模块存储在使用 .la 扩展名的文件中：
module_name.la
后端 存储或检索数据以响应 LDAP 请求。后端可以静态编译到
slapd 中，或者在启用模块支持时进行动态加载。在后一种情况下，应用以下命名规则：
back_backend_name.la
要载入模块或后端，请在
/etc/openldap/slapd.d/ 中使用以下指令：
-
olcModuleLoad - The
olcModuleLoad指令指定要加载的可动态加载的模块。它采用以下形式：olcModuleLoad: module此处，模块 表示要加载的模块或后端的文件。
9.2.4. 使用 LDAP 的应用程序的 SELinux 策略
SELinux 是在 Linux 内核中强制访问控制机制的一种实施。默认情况下，SELinux 会阻止应用访问 OpenLDAP 服务器。要通过 LDAP 启用身份验证（被多个应用程序需要），需要启用
allow_ypbind SELinux 布尔值。某些应用程序还需要在这种情况下启用的 authlogin_nsswitch_use_ldap 布尔值。执行以下命令启用上述布尔值：
~]# setsebool-Pallow_ypbind=1
~]# setsebool-Pauthlogin_nsswitch_use_ldap=1
P
选项使 此设置在系统重启后持久保留。有关 SELinux 的详情，请参阅 Red Hat Enterprise Linux 7 SELinux 用户和管理员指南。
9.2.5. 运行 OpenLDAP 服务器
这部分论述了如何启动、停止、重启和检查 独立 LDAP 守护进程 的当前状态。有关如何一般管理系统服务的更多信息，请参阅《 系统管理员指南》中的使用 systemd 管理服务。
9.2.5.1. 启动服务
要在当前会话中启动
slapd 服务，以 root 用户身份在 shell 提示符后输入以下内容：
~]# systemctl start slapd.service
要将服务配置为在引导时自动启动，请以
root 用户身份运行以下命令：
~]# systemctl enable slapd.service
ln -s '/usr/lib/systemd/system/slapd.service' '/etc/systemd/system/multi-user.target.wants/slapd.service'9.2.5.2. 停止服务
要在当前会话中停止正在运行的
slapd 服务，以 root 用户身份在 shell 提示符后输入以下内容：
~]# systemctl stop slapd.service
要防止服务在引导时自动启动，以
root 用户身份键入：
~]# systemctl disable slapd.service
rm '/etc/systemd/system/multi-user.target.wants/slapd.service'9.2.5.3. 重启服务
要重启正在运行的
slapd 服务，在 shell 提示符后输入以下内容：
~]# systemctl restart slapd.service
这将停止 服务，并立即重新启动该服务。使用此命令重新加载配置。
9.2.5.4. 验证服务状态
要验证
slapd 服务是否正在运行，在 shell 提示符后输入以下内容：
~]$ systemctl is-active slapd.service
active9.2.6. 使用 OpenLDAP 将系统配置为验证
若要将系统配置为使用 OpenLDAP 进行身份验证，请确保在 LDAP 服务器和客户端计算机上都安装了相应的软件包。有关如何设置服务器的详情，请按照 第 9.2.2 节 “安装 OpenLDAP 套件” 和 第 9.2.3 节 “配置 OpenLDAP 服务器” 中的说明进行操作。在客户端中，在 shell 提示符后输入以下内容：
~]# yum install openldap openldap-clients nss-pam-ldapd9.2.6.1. 将旧身份验证信息迁移到 LDAP 格式
migrationtools 软件包提供了一组 shell 和 Perl 脚本，可帮助您将身份验证信息迁移到 LDAP 格式。要安装这个软件包，在 shell 提示符后输入以下内容：
~]# yum install migrationtools
这会将脚本安装到
/usr/share/migrationtools/ 目录中。安装后，编辑 /usr/share/migrationtools/migrate_common.ph 文件并更改以下行以反映正确的域，例如：
# Default DNS domain $DEFAULT_MAIL_DOMAIN = "example.com"; # Default base $DEFAULT_BASE = "dc=example,dc=com";
或者，您也可以直接在命令行中指定环境变量。例如，要运行
migrate_all_online.sh 脚本，并将默认基础设置为 dc=example,dc=com，请输入：
~]# export DEFAULT_BASE="dc=example,dc=com" \ /usr/share/migrationtools/migrate_all_online.sh
要决定运行哪个脚本来迁移用户数据库，请参阅 表 9.8 “常用的 LDAP 迁移脚本”。
表 9.8. 常用的 LDAP 迁移脚本
| 现有名称服务 | LDAP 是否正在运行？ | 脚本使用 |
|---|---|---|
/etc flat 文件 | 是 | migrate_all_online.sh |
/etc flat 文件 | 否 | migrate_all_offline.sh |
| NetInfo | 是 | migrate_all_netinfo_online.sh |
| NetInfo | 否 | migrate_all_netinfo_offline.sh |
| NIS(YP) | 是 | migrate_all_nis_online.sh |
| NIS(YP) | 否 | migrate_all_nis_offline.sh |
有关如何使用这些脚本的更多信息，请参阅
/usr/share/doc/migrationtools-version/ 目录中的 README 和 migration-tools.txt 文件。
9.2.7. 其它资源
以下资源提供有关轻量级目录访问协议的额外信息。在系统上配置 LDAP 之前，强烈建议您查阅这些资源，尤其是 OpenLDAP 软件管理员指南。
安装的文档
以下文档随 openldap-servers 软件包一起安装：
/usr/share/doc/openldap-servers-版本/guide.html- OpenLDAP 软件管理员指南 的副本。/usr/share/doc/openldap-servers-版本/README.schema- 包含已安装模式文件描述的 README 文件。
另外，还安装 openldap、openldap-servers 和 openldap-clients 软件包的 man page:
- 客户端应用程序
- ldapadd(1) - ldapadd 命令的手册页描述了如何在 LDAP 目录中添加条目。
- ldapdelete(1) - ldapdelete 命令的手册页描述了如何删除 LDAP 目录中的条目。
- ldapmodify(1) - ldapmodify 命令的手册页描述了如何修改 LDAP 目录中的条目。
- ldapsearch(1) - ldapsearch 命令的手册页描述了如何搜索 LDAP 目录中的条目。
- ldappasswd(1) - ldappasswd 命令的手册页描述了如何设置或更改 LDAP 用户的密码。
- ldapcompare(1) - 描述如何使用 ldapcompare 工具。
- ldapwhoami(1) - 描述如何使用 ldapwhoami 工具。
- ldapmodrdn(1) - 描述如何修改条目的 RDNs。
- 服务器应用程序
- slapd(8C) - 描述 LDAP 服务器的命令行选项。
- 管理应用程序
- slapadd(8C) - 描述用于在 slapd 数据库中添加条目的命令行选项。
- slapcat(8C) - 描述用于从 slapd 数据库生成 LDIF 文件的命令行选项。
- slapindex(8C) - 描述用于根据 slapd 数据库的内容重新生成索引的命令行选项。
- slappasswd(8C) - 描述用于为 LDAP 目录生成用户密码的命令行选项。
- 配置文件
- ldap.conf(5) -
ldap.conf文件的手册页描述了 LDAP 客户端配置文件中可用的格式和选项。 - slapd-config(5) - 描述
/etc/openldap/slapd.d配置目录中可用的格式和选项。
其他资源
- OpenLDAP 和 Mozilla NSS 兼容性层 实施详情（NSS 数据库向后兼容性）
- 我如何使用 TLS/SSL？有关如何将 OpenLDAP 配置为使用 OpenSSL 的信息。
部分 III. 安全应用程序
本节详细介绍了如何使用
可插拔验证模块 (PAM)，如何使用 Kerberos 身份验证协议和 certmonger 守护进程，最后，如何为 单点登录 (SSO)配置应用程序。
第 10 章 使用可插拔验证模块(PAM)
可插拔验证模块 (PAM)是身份验证和授权的通用框架。Red Hat Enterprise Linux 中的大多数系统应用程序依赖于底层 PAM 配置进行身份验证和授权。
10.1. 关于 PAM
可插拔验证模块(PAM)提供集中式身份验证机制，系统应用可以使用此机制将身份验证中继到集中配置的框架。
PAM 可插拔，因为存在用于不同类型的身份验证源（如 Kerberos、SSSD、NIS 或本地文件系统）的 PAM 模块。可以优先使用不同的身份验证源。
此模块化架构为管理员提供了很大的灵活性来为系统设置身份验证策略。PAM 对开发人员和管理员而言是有用的系统，原因如下：
- PAM 提供一种常见身份验证方案，可用于各种应用。
- PAM 为系统管理员提供了对身份验证的显著灵活性和控制力。
- PAM 提供单个全文档库，允许开发人员编写程序，而无需创建自己的身份验证方案。
10.1.1. 其他 PAM 资源
PAM 有一个丰富的文档集，其中更详细地说明了使用 PAM 和编写模块来扩展或集成 PAM 与其他应用程序。使用 PAM 的几乎所有主要模块和配置文件都有其自己的 man page。另外，
/usr/share/doc/ pam-version#/ 目录包含 系统管理员指南、Module Writers' Manual 和 Application Developers 的 Manual，以及 PAM 标准 DCE-RFC 86.0 的副本。
PAM 的库位于： http://www.linux-pam.org这是 Linux-PAM 项目的主要发行网站，包含有关各种 PAM 模块的信息、常见问题和其他 PAM 文档。
10.1.2. 自定义 PAM 模块
可以随时创建新的 PAM 模块，供 PAM 感知型应用程序使用。感知 PAM 的程序可以立即使用新模块及其定义的任何方法，而无需重新编译或修改。这使得开发人员和系统管理员能够为不同的程序使用一系列身份验证模块和测试，无需重新编译它们。
有关编写模块的文档包含在
/usr/share/doc/pam-devel-version#/ 目录中。
10.2. 关于 PAM 配置文件
每个 PAM 感知 应用程序或服务 在
/etc/pam.d/ 目录中都有一个文件。此目录中的每一文件的名称与其控制访问权限的服务相同。例如，登录程序将其服务名称定义为 login，并安装 /etc/pam.d/ login PAM 配置文件。
警告
强烈建议您使用 authconfig 工具配置 PAM，而不是手动编辑 PAM 配置文件。
10.2.1. PAM 配置文件格式
每个 PAM 配置文件包含一组指令，这些指令定义模块（身份验证配置区域）以及其中的任何控制或参数。
这些指令都具有简单的语法，可识别模块用途（接口）和模块的配置设置。
module_interface control_flag module_name module_arguments
在 PAM 配置文件中，模块接口是定义的第一个字段。例如：
auth required pam_unix.so
PAM 接口 基本上是该特定模块可以执行的身份验证操作类型。可用的 PAM 模块接口有四种，分别对应于身份验证和授权过程的不同方面：
- auth - 此模块接口验证用户。例如，它请求并验证密码的有效性。带有此接口的模块也可以设置凭据，如组成员资格。
- account - 此模块接口验证是否允许访问。例如，它会检查用户帐户是否已过期，或者是否允许用户在特定时刻登录。
- password - 此模块接口用于更改用户密码。
- Session - 此模块接口配置和管理用户会话。使用此界面的模块还可以执行允许访问所需的其他任务，例如挂载用户的主目录和使用户的邮箱可用。
单个模块可以提供任何或所有模块接口。例如，
pam_unix.so 提供所有四个模块接口。
模块名称（如 pam_unix.so ）为 PAM 提供包含指定模块接口的库名称。目录名称会被省略，因为应用程序链接到适当的
libpam 版本，它可以找到模块的正确版本。
调用时，所有 PAM 模块都会生成成功或失败的结果。控制标志 告诉 PAM 如何使用结果。可以按特定顺序列出（堆叠）模块，控制标志则决定特定模块的成功或失败对于向用户验证服务的整体目标而言有多重要。
有几个简单标记[2]，它只使用关键字来设置配置：
- 必需 - 模块结果必须成功才能进行身份验证才能继续。如果此时测试失败，则只有在所有模块测试引用该接口完成之前，才会通知用户。
- requisite - 模块结果必须成功才能继续身份验证。但是，如果测试在此时失败，用户会立即收到一个显示第一个 failed 或 requisite 模块测试的消息。
- sufficient - 如果模块失败，则忽略该模块结果。但是，如果模块标记 足够 成功，并且没有 以前的模块标记失败，则不需要其他结果，用户会被验证到该服务。
- 可选 - 模块结果会被忽略。在没有其他模块引用 接口时，只有在成功进行身份验证时，才会将模块标记为可选。
- include - 与其他控制不同，这与处理模块结果无关。此标志拉取配置文件中与给定参数匹配的所有行，并将它们作为参数附加到模块。
模块接口指令可以 堆叠 或放在另一个模块上，从而能将多个模块一起用于一个用途。
注意
如果模块的 control 标志使用了
sufficient 或 requisite 值，则列出模块的顺序对身份验证过程非常重要。
利用堆栈，管理员可以先存在特定条件，然后才能允许用户进行身份验证。例如，setup 工具通常使用几个堆栈的模块，如其 PAM 配置文件中所示：
[root@MyServer ~]# cat /etc/pam.d/setup auth sufficient pam_rootok.so auth include system-auth account required pam_permit.so session required pam_permit.so
auth sufficient pam_rootok.so- 此行使用pam_rootok.so模块来检查当前用户是否为 root，方法是验证其 UID 是否为 0。如果此测试成功，则不会查询其他模块并执行 命令。如果此测试失败，则使用下一个模块。auth 包括 system-auth- 此行包含/etc/pam.d/system-auth模块的内容，并处理此内容进行验证。帐户 required pam_permit.so- 此行使用pam_permit.so模块来允许 root 用户或在控制台中登录的任何人都重新引导系统。会话 required pam_permit.so- 此行与会话设置相关。使用pam_permit.so，它会确保setup实用程序不会失败。
PAM 使用 参数 将信息传递至某些模块的身份验证期间可插拔模块。
例如，
pam_pwquality.so 模块检查密码的强度程度，并可取几个参数。在以下示例中，force _for_root 指定即使 root 用户的密码也必须成功通过强度检查，然后 重试 定义用户将收到三个输入强密码的机会：
password requisite pam_pwquality.so enforce_for_root retry=3
无效的参数通常会被忽略，否则不会影响 PAM 模块的成功或失败。但是，一些模块可能会在无效的参数中失败。大多数模块向
journald 服务报告错误。有关如何使用 journald 和相关 journalctl 工具的详情，请参考 系统管理员指南。
注意
journald 服务在 Red Hat Enterprise Linux 7.1 中引入。在以前的 Red Hat Enterprise Linux 版本中，大多数模块会向 /var/log/secure 文件报告错误。
10.2.2. 注解的 PAM 配置示例
例 10.1 “简单的 PAM 配置” 是 PAM 应用程序配置文件示例：
例 10.1. 简单的 PAM 配置
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_pwquality.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- 第一行是注释，由行首处的 hash 标记(#)表示。
- 第二行（共四个堆栈）三个模块进行登录身份验证。auth required pam_securetty.so - 此模块可确保如果用户尝试以 root 身份登录，如果该文件存在，则
/etc/securetty文件中列出了用户正在登录的 TTY。如果 TTY 没有列在文件中，则任何尝试以 root 身份登录都会失败，并显示Login incorrect信息。auth required pam_unix.so nullok - 此模块提示用户输入密码，然后使用存储在/etc/passwd中的信息检查密码（如果存在的话），以及/etc/shadow。参数 nullok 指示pam_unix.so模块允许空白密码。 - auth required pam_nologin.so - 这是最终身份验证步骤。它将检查
/etc/nologin文件是否存在。如果存在并且用户不是 root，则身份验证会失败。注意在本例中，会检查所有三个 auth 模块，即使第一个 auth 模块失败。这可以防止用户在什么阶段知道其身份验证失败。这种在攻击者手中的知识让他们可以更容易地推断出如何破解系统。 - 帐户所需的 pam_unix.so - 此模块执行任何必要的帐户验证。例如，如果启用了 shadow 密码，
pam_unix.so模块的帐户接口检查帐户是否已过期，或者用户是否在允许的宽限期中更改了密码。 - password required pam_pwquality.so retry=3 - 如果密码已过期，
pam_pwquality.so模块的密码组件会提示输入新密码。然后，它会测试新创建的密码，看它是否能由基于字典的密码破解程序轻松确定。参数 retry=3 指定测试第一次失败，则用户有另外两个机会来创建强密码。 - password required pam_unix.so shadow nullok use_authtok - 如果程序使用
pam_unix.so模块 的密码 接口更改用户的密码，则指定此行。- 参数 shadow 指示模块在更新用户密码时创建影子密码。
- 参数 nullok 指示模块允许用户从空白密码更改其密码，否则 null 密码被视为帐户锁定。
- 这一行上的最后一个参数 use_authtok 提供了堆栈 PAM 模块时顺序的重要性的好示例。此参数指示模块不要提示用户输入新密码。相反，它接受之前 password 模块记录的任何密码。这样，所有新密码都必须传递
pam_pwquality.so测试安全密码，然后才能被接受。
- session required pam_unix.so - 最后一行指示
pam_unix.so模块的会话接口来管理会话。此模块将用户名和服务类型记录到每个会话的开头和结尾处的/var/log/secure中。此模块可通过与其他会话模块堆栈来获取额外的功能来补充。
10.3. PAM 和管理凭证缓存
Red Hat Enterprise Linux 中有多个图形管理工具，如 GNOME 的
control-center，用户可以使用 pam_timestamp.so 模块为用户提供最多 5 分钟的权限。务必要了解此机制的工作方式，因为在 pam_timestamp.so 过程中离开终端的用户使机器处于打开状态，以使机器可以被具有物理访问权限的任何人进行操作。
在 PAM 时间戳方案中，图形管理应用在启动时提示用户输入 root 密码。当用户通过身份验证后，
pam_timestamp.so 模块会创建一个时间戳文件。默认情况下，这在 /var/run/sudo/ 目录中创建。如果时间戳文件已存在，图形管理程序不会提示输入密码。相反，pam_timestamp.so 模块会重新设置时间戳文件，从而保留一个额外的五分钟，为用户保留一个未限制的管理访问权限。
您可以通过检查
/var/run/sudo/用户 目录中的文件来验证时间戳文件的实际状态。对于桌面，相关文件为 unknown:root。如果存在，其时间戳少于五分钟，则凭证有效。
时间戳文件的存在通过身份验证图标表示，该图标出现在面板的通知区域中。
图 10.1. 身份验证图标
[D]
10.3.1. Common pam_timestamp 指令
pam_timestamp.so 模块提供这两个接口：
- auth
- 会话
另外，以下选项可用于
pam_timestamp.so ：
- timestamp_timeout: 指定时间戳文件的有效性周期（以秒为单位），默认为 300 (five minutes)。
- timestampdir: 指定在哪些目录中存储时间戳文件，默认为 /var/run/sudo/。
- 您还可以使用 verbose 或 debug 获取更详细的消息。
例如：
auth sufficient pam_timestamp.so timestamp_timeout=600 session optional pam_timestamp.so
10.3.2. 删除时间戳文件
在放弃激活 PAM 时间戳的控制台之前，建议销毁时间戳文件。要在图形环境中执行此操作，请单击面板上的验证图标。这将导致显示对话框。点 按钮销毁活跃的时间戳文件。
图 10.2. 取消验证对话框
[D]
PAM 时间戳文件有一些重要特征：
- 如果使用 ssh 远程登录到系统，请使用 /sbin/pam_timestamp_check -k root 命令销毁时间戳文件。
- 从启动特权应用程序的同一终端窗口中，运行 /sbin/pam_timestamp_check -k root 命令。
- 最初调用
pam_timestamp.so模块的登录用户必须是运行 /sbin/pam_timestamp_check -k 命令的用户。不要以 root 身份运行此命令。 - 在桌面上终止凭证，而无需对图标使用 操作，可以使用 /sbin/pam_timestamp_check 命令完成。
/sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
任何其他方法仅从运行命令的 PTY 中删除凭据。
有关使用
pam_timestamp_check 销毁时间戳文件的更多信息，请参阅 pam_timestamp_check 手册页。
10.4. 为 PAM 服务限制域
重要
此功能要求 SSSD 在系统中运行。
SSSD 允许您限制 PAM 服务可以访问哪些域。SSSD 根据特定 PAM 服务运行的用户评估来自 PAM 服务的身份验证请求。PAM 服务是否可以访问 SSSD 域取决于 PAM 服务用户是否能够访问该域。
示例用例是允许外部用户进行 FTP 服务器身份验证的环境。FTP 服务器作为单独的非特权用户运行，该用户应只能向选定的 SSSD 域进行身份验证，独立于内部公司帐户。使用此功能，管理员可以仅允许 FTP 用户对 FTP PAM 配置文件中指定的选定域进行身份验证。
注意
这个功能与旧的 PAM 模块类似，如
pam_ldap，它能够使用单独的配置文件作为 PAM 模块的参数。
限制访问域的选项
以下选项可以用来限制对所选域的访问：
/etc/sssd/sssd.conf中的pam_trusted_users- 这个选项接受代表 SSSD 要信任的 PAM 服务的数字 UID 或用户名列表。默认设置是
all，这意味着所有服务用户都是受信任的，可以访问任何域。 /etc/sssd/sssd.conf中的pam_public_domains- 这个选项接受公共 SSSD 域列表。公共域是即使不可信 PAM 服务用户也可访问的域。选项也接受
all和none值。默认值为none，这意味着没有域是公共域，因此不受信任的服务用户无法访问任何域。 - PAM 配置文件的
域 - 此选项指定 PAM 服务可以对其进行身份验证的域列表。如果您在没有指定任何
域的情况下使用域，PAM 服务将无法对任何域进行身份验证，例如：auth required pam_sss.so domains=如果 PAM 配置文件中没有使用域，PAM 服务可以在服务在可信用户下运行的条件上对所有域进行身份验证。/etc/sssd/sssd.confSSSD 配置文件中的domain选项还指定 SSSD 尝试验证的域列表。请注意，PAM配置文件中的 domain 选项无法扩展sssd.conf中的域列表，它只能通过指定较短的列表来限制sssd.conf域列表。因此，如果在 PAM 文件中指定了域，但没有在sssd.conf中指定，PAM 服务将无法对域进行身份验证。
默认设置
pam_trusted_users = all and pam_public_domains = none 指定所有 PAM 服务用户都是可信并可访问任何域。在这种情况下，PAM 配置文件的 domain 选项 可用于限制可访问的域。
如果您使用 PAM 配置文件中的
域 来指定域，sssd.conf 包含 pam_public_domains，则可能需要在 pam_public_domains 中指定域。如果使用 pam_public_domains，但没有包含所需域，则 PAM 服务将无法成功对域进行身份验证（如果其在不受信任的用户下运行）。
注意
PAM 配置文件中定义的域限制仅适用于身份验证操作，不适用于用户查找。
有关
pam_trusted_users 和 pam_public_domains 选项的详情请参考 sssd.conf(5) man page。有关 PAM 配置文件中使用 的域 选项的详情请参考 pam_sss(8) man page。
例 10.2. 为 PAM 服务限制域
要限制 PAM 服务可对其进行身份验证的域：
- 确保 SSSD 已配置为访问所需的域或域。SSSD 可以进行身份验证的域在
/etc/sssd/sssd.conf文件中的domains选项中定义。[sssd] domains = domain1, domain2, domain3
- 指定 PAM 服务能够进行身份验证的域或域。为此，可在 PAM 配置文件中设置 domain
选项。例如：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 进行身份验证。
第 11 章 使用 Kerberos
在网络中维护系统安全性和完整性至关重要，它包括网络基础架构中的每个用户、应用程序、服务和服务器。需要了解在网络上运行的所有内容以及使用这些服务的方式。保持这种安全性的核心在于维护对这些应用和服务 的访问 并强制实施该访问。
Kerberos 是一种身份验证协议，明显比基于密码的普通身份验证更加安全。借助 Kerberos，密码绝不会通过网络发送，即使在其他计算机上访问服务也是如此。
Kerberos 提供了一种机制，允许用户和计算机向网络表明自己身份并接收对管理员配置的区域和服务进行定义的有限访问权限。Kerberos 通过验证其身份 来验证实体，Kerberos 还可保护此数据的身份验证，使其不能被外部人员访问和使用和使用。
11.1. 关于 Kerberos
Kerberos 使用对称密钥加密[3] 要验证用户到网络服务的身份验证，这意味着密码实际上不会通过网络发送。
因此，当用户使用 Kerberos 向网络服务进行身份验证时，试图通过监控网络流量来收集密码的未授权用户实际上会被阻止。
11.1.1. Kerberos 工作方式的基础知识
大多数传统网络服务使用基于密码的身份验证方案，即用户提供密码以访问给定的网络服务。但是，许多服务的身份验证信息的传输是不加密的。为了使这种方案安全，网络必须不可被外部人员访问，并且网络上的所有计算机和用户都必须信任和信赖。
通过基于密码的简单身份验证，无法认为连接到互联网的网络是安全的。任何获得网络访问权限的攻击者都可以使用简单的数据包分析器或 数据包嗅探器 来拦截用户名和密码，威胁用户帐户，从而影响整个安全基础架构的完整性。
Kerberos 消除了网络上未加密密码的传输，并消除了攻击者窃听网络的潜在威胁。
Kerberos 使用对称加密和可信第三方（一个 密钥分发中心 或 KDC）对用户进行身份验证，而不是像简单密码身份验证一样单独向每个网络服务验证用户。由该 KDC 和任何辅助 KDC 管理的计算机组成一个 域。
当用户向 KDC 进行身份验证时，KDC 会为该会话发送一组特定于该会话的凭据（ 票据）回用户的计算机，而任何 Kerberos 感知服务都会查找用户机器上的票据，而不是要求用户使用密码进行身份验证。
如 图 11.1 “Kerberos 身份验证” 所示，每个用户都标识到带有唯一身份的 KDC，称为 主体。当 Kerberos 感知网络中的用户登录到其工作站时，作为来自身份验证服务器的 票据 （或 TGT）请求的一部分，他的主体会被发送到 KDC。此请求可由登录程序发送，使其对用户透明，也可以在用户登录后通过 kinit 程序手动发送。
然后，KDC 会检查数据库中的主体。如果找到主体，KDC 会创建一个 TGT，使用用户的密钥对其进行加密，并将 TGT 发送到该用户。
图 11.1. Kerberos 身份验证
然后，客户端上的 login 或 kinit 程序使用用户的密钥解密 TGT，该密钥从用户的密码计算。用户的密钥仅在客户端计算机上使用，不会 通过网络传输。KDC 发送的票据（或凭证）存储在本地存储中，凭据缓存(ccache) 可以被 Kerberos 感知服务检查。Red Hat Enterprise Linux 7 支持以下类型的凭证缓存：
- 持久性 KEYRING ccache 类型，Red Hat Enterprise Linux 7 中的默认缓存
- 系统安全服务守护进程(SSSD)Kerberos 凭据管理器(KCM)，这是 Red Hat Enterprise Linux 7.4 起的替代选项
- FILE
- DIR
- MEMORY
使用 SSSD KCM 时，Kerberos 缓存不存储在被动存储中，而是由守护进程管理。在这个设置中，Kerberos 库通常由
kinit 等应用程序使用，是一个 KCM 客户端，守护进程被称为 KCM 服务器。
使用由 SSSD KCM 守护进程管理的 Kerberos 凭证缓存有几个优点：
- 守护进程有状态，可以执行 Kerberos 凭据缓存续订或恢复旧 ccache 等任务。续订和跟踪不仅可能适用于 SSSD 本身获取的票据，通常是通过
pam_sss.so登录，也适用于获取票据，例如 kinit。 - 由于进程在用户空间中运行，因此它受到 UID 命名空间的限制，这与内核 KEYRING 不同。
- 基于 Kernel KEYRING 的缓存（完全依赖于调用者的 UID），以及容器化环境中在所有容器中共享的基于 Kernel KEYRING 的缓存不同，KCM 服务器的入口点是只能绑定到所选容器的 UNIX 套接字。
身份验证后，服务器可以检查可识别主体及其密钥的未加密的列表，而不是检查 kinit; 这保存在 keytab 中。
TGT 设置为在特定时间段（通常为 10 小时至 24 小时）后过期，并存储在客户端计算机的凭证缓存中。设定了一个过期时间，以便一个被入侵的 TGT 仅在短时间内被攻击者使用。在 TGT 发出后，用户不必再次输入密码，直到 TGT 过期或直到他们注销并再次登录为止。
每当用户需要访问网络服务时，客户端软件使用 TGT 从票据授权服务器(TGS)请求该特定服务的新票据。服务票据随后用于以透明的方式向该服务验证用户。
11.1.2. 关于 Kerberos 主体名称
主体不仅标识用户或服务，也标识该实体所属的域。主体名称包含两个部分：标识符和域：
identifier@REALM
对于用户，标识符 只是 Kerberos 用户名。对于服务，标识符 是服务名称和其运行机器的主机名的组合：
service/FQDN@REALM
服务名称 是一个特定于服务类型的区分大小写的字符串，如 host、ldap、http 和 DNS。并非所有服务都有明显的主体标识符；例如，
sshd 守护进程都使用主机服务主体。
主机主体通常存储在
/etc/krb5.keytab 中。
当 Kerberos 请求一个票据时，它会始终将域名别名（DNS CNAME 记录）解析为对应的 DNS 地址（A 或 AAAA 记录）。然后，在创建服务或主机主体时使用地址记录的主机名。
例如：
www.example.com CNAME web-01.example.com web-01.example.com A 192.0.2.145
服务尝试使用其 CNAME 别名连接到主机：
$ ssh www.example.com
Kerberos 服务器为解析的主机名 web-01.example.com@EXAMPLE.COM 请求一个 ticket，因此主机主体必须是 host/web-01.example.com@EXAMPLE.COM。
11.1.3. 关于 Domain-to-Realm 映射
客户端尝试访问特定服务器上运行的服务时，它知道服务的名称(host)和服务器的名称(foo.example.com)，但由于可以在网络上部署多个域，因此它必须猜测该服务所在的 Kerberos 域的名称。
默认情况下，realm 的名称取为服务器在所有大写字母中的 DNS 域名。
foo.example.org → EXAMPLE.ORG foo.example.com → EXAMPLE.COM foo.hq.example.com → HQ.EXAMPLE.COM
在某些配置中，这已经足够了，但在其他配置中，派生的域名将是不存在的域的名称。在这些情况下，必须在客户端系统
/etc/krb5.conf 文件的 domain_realm 部分中指定从服务器的 DNS 域名到其域名的映射。例如：
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
配置指定了两个映射：第一个映射指定 example.com DNS 域中的任何系统都属于 EXAMPLE.COM 域。第二个命令指定名称为 example.com 的系统也位于 realm 中。域和特定主机之间的区别由存在或缺少初始句点字符来标记。映射还可使用 "_kerberos TXT" 记录直接存储在 DNS 中，例如：
$ORIGIN example.com _kerberos TXT "EXAMPLE.COM"
11.1.4. 环境要求
Kerberos 依赖于能够解析机器名称。因此，它需要一个有效的域名服务(DNS)。必须正确配置网络上的 DNS 条目和主机，这包括在
/usr/share/doc/krb5-server-version-number 的 Kerberos 文档中。
接受 Kerberos 身份验证的应用程序需要时间同步。您可以使用 ntpd 等服务在网络上的机器间设置大约时钟同步。有关
ntpd 服务的详情，请查看 /usr/share/doc/ntp-version-number/html/index.html 或 ntpd(8) man page 中的文档。
注意
运行红帽企业 Linux 7 的 Kerberos 客户端支持使用 KDC 自动调整时间，并且没有严格的计时要求。这样，在使用红帽企业 Linux 7 部署 IdM 客户端时，可以更好地容忍调整差异。
11.1.5. 部署 Kerberos 的注意事项
尽管 Kerberos 消除了常见且严重的安全威胁，但出于各种原因很难实施：
- Kerberos 假定每个用户都是受信任的，但在不可信网络上使用不受信任的主机。其主要目标是防止未加密密码在这个网络中传输。但是，如果除正确用户之外的任何人都有权访问一个主机，发行用于身份验证的票据 - KDC - 整个 Kerberos 身份验证系统都处于风险之中。
- 若要让应用使用 Kerberos，必须修改其源才能对 Kerberos 库进行适当的调用。以这种方式修改的应用程序被视为可 识别 Kerberos。对于某些应用，由于应用或设计的大小，这可能会非常有问题。对于其他不兼容的应用，必须对服务器和客户端的通信方式进行更改。再强调一下，这可能需要进行大量的编程。默认情况下没有 Kerberos 支持的闭源应用程序通常是最令人烦恼的问题。
- 要通过 Kerberos 保护网络，必须使用 所有 客户端和服务器应用的 Kerberos 感知版本，这些客户端和服务器应用程序必须传输未加密的密码，或者根本不使用该客户端和服务器应用程序。
- 将用户密码从标准 UNIX 密码数据库（如
/etc/passwd或/etc/shadow）迁移到 Kerberos 密码数据库可能非常小心。没有可执行此任务的自动机制。迁移方法可能会有很大差异，具体取决于 Kerberos 的部署方式。这就是建议您使用身份管理功能的原因；它有专门的迁移工具和方法。
警告
如果网络上的用户通过以纯文本形式传输密码，对非 Kerberos 识别服务进行身份验证，则 Kerberos 系统可能会受到威胁。强烈建议使用非 Kerberos 感知服务（包括 telnet 和 FTP）。其他加密协议（如 SSH 或 SSL 保护的服务）优先于未加密的服务，但这仍然不理想。
11.1.6. Kerberos 的其他资源
Kerberos 可能是一项要实施的复杂服务，在部署方式上具有很大的灵活性。表 11.1 “外部 Kerberos 文档” 表 11.2 “重要的 Kerberos man page” 列出了一些最重要的或最有用的源，以了解有关使用 Kerberos 的更多信息。
表 11.1. 外部 Kerberos 文档
| Documentation | 位置 |
|---|---|
| Kerberos V5 安装指南（在 PostScript 和 HTML 中） | /usr/share/doc/krb5-server-version-number |
| Kerberos V5 系统管理员指南（在 PostScript 和 HTML 中） | /usr/share/doc/krb5-server-version-number |
| Kerberos V5 UNIX 用户指南（在 PostScript 和 HTML 中） | /usr/share/doc/krb5-workstation-version-number |
| "Kerberos：网络身份验证协议"网页来自 MIT | http://web.mit.edu/kerberos/www/ |
| 设计身份验证系统：在四个 Scenes 中，最初由 44 年的 Bill Bryant 组成，于 2001 年由 Theodore Tso 修改。本文档是两个开发人员之间的对话，他们正考虑创建 Kerberos 风格的身份验证系统。对于完全不熟悉 Kerberos 的人而言，讨论方式使这一点是一个不错的起点。 | http://web.mit.edu/kerberos/www/dialogue.html |
| 使网络 Kerberos 感知的文章. | http://www.ornl.gov/~jar/HowToKerb.html |
任何手册页文件都可以通过运行 man command_name 打开。
表 11.2. 重要的 Kerberos man page
| manpage | Description |
|---|---|
| 客户端应用程序 | |
kerberos | Kerberos 系统简介，该系统描述了凭据的工作原理，并提供获取和销毁 Kerberos 票据的建议。man page 的底部引用了多个相关的 man page。 |
| kinit | 描述如何使用这个命令来获取和缓存一个票据获取和缓存。 |
| kdestroy | 描述如何使用这个命令销毁 Kerberos 凭证。 |
| klist | 描述如何使用这个命令列出缓存的 Kerberos 凭证。 |
| 管理应用程序 | |
| kadmin | 描述如何使用这个命令来管理 Kerberos V5 数据库。 |
| kdb5_util | 描述如何使用此命令在 Kerberos V5 数据库中创建和执行低级别管理功能。 |
| 服务器应用程序 | |
| krb5kdc | 描述 Kerberos V5 KDC 的可用命令行选项。 |
| kadmind | 描述 Kerberos V5 管理服务器可用的命令行选项。 |
| 配置文件 | |
krb5.conf | 描述在 Kerberos V5 库配置文件中提供的格式和选项。 |
kdc.conf | 描述 Kerberos V5 AS 和 KDC 配置文件中提供的格式和选项。 |
11.2. 配置 Kerberos KDC
首先安装主 KDC，然后在设置主服务器后安装任何必要的次要服务器。
重要
不建议手动设置 Kerberos KDC。在 Red Hat Enterprise Linux 环境中引入 Kerberos 的建议方法是使用身份管理功能。
11.2.1. 配置主 KDC 服务器
重要
KDC 系统应为专用计算机。此计算机需要非常安全 - 如果可能，它不应运行 KDC 以外的任何服务。
- 为 KDC 安装所需的软件包：
[root@server ~]# yum install krb5-server krb5-libs krb5-workstation
- 编辑
/etc/krb5.conf和/var/kerberos/krb5kdc/kdc.conf配置文件，以反映 realm 名称和 domain-to-realm 映射。例如：[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM可以通过将 EXAMPLE.COM 和 example.com 的实例替换为正确的域名来构建一个简单的域 - 务必使大写和小写名称保留正确的格式 - 并通过将 KDC 从 kerberos.example.com 更改为 Kerberos 服务器的名称。按照惯例，所有域名均为大写，所有 DNS 主机名和域名均为小写。这些配置文件的 man page 提供有关文件格式的完整详情。 - 使用 kdb5_util 实用程序创建数据库。
[root@server ~]# kdb5_util create -s
create 命令创建为 Kerberos 域存储密钥的数据库。-s 参数会创建一个存储主服务器密钥的 stash 文件。如果没有从中读取密钥的 stash 文件，则 Kerberos 服务器(krb5kdc)会提示用户输入 master 服务器密码（可用于重新生成密钥）。 - 编辑
/var/kerberos/krb5kdc/kadm5.acl文件。kadmind 使用此文件来确定哪些主体对 Kerberos 数据库及其访问级别具有管理访问权限。例如：*/admin@EXAMPLE.COM *
大多数用户在数据库中由一个主体（使用 NULL 或空实例，如 joe@EXAMPLE.COM）表示。在这个配置中，具有第二个主体的用户 （ 例如 joe/admin@EXAMPLE.COM）可以全面控制域的 Kerberos 数据库。在服务器上启动 kadmind 后，任何用户都可以在域中的任何客户端或服务器上运行 kadmin 来访问其服务。但是，除了更改自己的密码外，只有kadm5.acl文件中列出的用户才能以任何方式修改数据库。注意kadmin 工具通过网络与 kadmind 服务器通信，并使用 Kerberos 处理身份验证。因此，第一个主体必须已经存在，然后才能通过网络连接到服务器来管理它。使用 kadmin.local 命令创建第一个主体，该命令专门设计为在与 KDC 相同的主机上使用，且不使用 Kerberos 进行身份验证。 - 在 KDC 终端中使用 kadmin.local 创建第一个主体：
[root@server ~]# kadmin.local -q "addprinc username/admin"
- 使用以下命令启动 Kerberos：
[root@server ~]# systemctl start krb5kdc.service [root@server ~]# systemctl start kadmin.service
- 在 kadmin 中使用 addprinc 命令为用户添加主体。kadmin 和 kadmin.local 是 KDC 的命令行界面。因此，启动 kadmin 程序后，可以使用许多命令，如 addprinc -。如需更多信息，请参阅 kadmin 手册页。
- 验证 KDC 是否在签发票据。首先，运行 kinit 以获取 ticket 并将其存储在凭证缓存中。接下来，使用 klist 查看缓存中凭据列表，并使用 kdestroy 销毁缓存及其包含的凭证。注意默认情况下，kinit 会尝试使用相同的系统登录用户名（而不是 Kerberos 服务器）进行身份验证。如果该用户名与 Kerberos 数据库中的主体没有对应，则 kinit 会发出错误消息。如果发生这种情况，请在命令行中以正确的主体名称作为参数提供 kinit ：
kinit principal
11.2.2. 设置第二个 KDC
当给定域有多个 KDC 时，一个 KDC ( 主 KDC)会保留 realm 数据库的可写副本并运行 kadmind。主 KDC 也是域的 管理服务器。其他辅助 KDC 保留数据库的只读副本，并运行 kpropd。
主和从属传播过程要求主 KDC 将其数据库转储到临时转储文件中，然后将该文件传输到每个从卷，然后使用转储文件的内容覆盖之前收到的数据库只读副本。
设置二级 KDC：
- 为 KDC 安装所需的软件包：
[root@slavekdc ~]# yum install krb5-server krb5-libs krb5-workstation
- 将主 KDC 的
krb5.conf和kdc.conf文件复制到辅助 KDC 中。 - 从主 KDC 上的 root shell 启动 kadmin.local。
- 使用 kadmin.local add_principal 命令为主 KDC 的主机服务创建新条目。
[root@masterkdc ~]# kadmin.local -r EXAMPLE.COM Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin: add_principal -randkey host/masterkdc.example.com Principal "host/masterkdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/masterkdc.example.com Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- 使用 kadmin.local ktadd 命令为服务设置随机密钥，并将随机密钥存储在 master 的默认 keytab 文件中。注意kprop 命令使用此密钥向次要服务器进行身份验证。无论您安装多少次要 KDC 服务器，您只需执行此操作一次。
- 从辅助 KDC 上的 root shell 启动 kadmin。
- 使用 kadmin.local add_principal 命令为辅助 KDC 的主机服务创建新条目。
[root@slavekdc ~]# kadmin -p jsmith/admin@EXAMPLE.COM -r EXAMPLE.COM Authenticating as principal jsmith/admin@EXAMPLE.COM with password. Password for jsmith/admin@EXAMPLE.COM: kadmin: add_principal -randkey host/slavekdc.example.com Principal "host/slavekdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- 使用 kadmin.local ktadd 命令为服务设置随机密钥，并将随机密钥存储在次要 KDC 服务器的默认 keytab 文件中。在验证客户端时，kpropd 服务使用此密钥。
- 借助其服务密钥，次要 KDC 可以验证要与之连接的任何客户端。显然，并非所有潜在的客户端都应被允许为 kprop 服务提供新的 realm 数据库。要限制访问，二级 KDC 上的 kprop 服务将只接受来自
/var/kerberos/krb5kdc/kpropd.acl中列出的主体名称的客户端。将主 KDC 主机服务的名称添加到该文件中。[root@slavekdc ~]# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
- 辅助 KDC 获取数据库的副本后，还需要用于加密的主密钥。如果 KDC 数据库的主密钥存储在主 KDC 上的 stash 文件中（通常称为
/var/kerberos/krb5kdc/.k5.REALM），则将其复制到辅助 KDC 中，或使用任何可用的安全方法将其复制到辅助 KDC 中，或者通过运行 kdb5_util create -s 并提供相同的密码。dummy 数据库将被第一次成功数据库传播覆盖。 - 确保辅助 KDC 的防火墙允许主 KDC 使用端口 754 (krb5_prop)上的 TCP 联系，并启动 kprop 服务。
- 验证 kadmin 服务 是否已禁用。
- 通过将主 KDC 上的 realm 数据库转储到要读取的默认数据文件(
/var/kerberos/krb5kdc/slave_datatrans)来执行手动数据库传播测试。[root@masterkdc ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
- 使用 kprop 命令将其内容传输到辅助 KDC。
[root@masterkdc ~]# kprop slavekdc.example.com
- 使用 kinit，验证客户端系统是否能够从 KDC 正确获取初始凭证。客户端的
/etc/krb5.conf应该只列出 KDC 列表中的辅助 KDC。[realms] EXAMPLE.COM = {kdc = slavekdc.example.com.:88admin_server = kdc.example.com default_domain = example.com } - 创建一个转储 realm 数据库的脚本，并运行 kprop 命令将数据库传送到每个辅助 KDC 中，并将 cron 服务配置为定期运行脚本。
11.2.3. Kerberos 密钥分发中心代理
有些管理员可能选择使其部署无法访问默认的 Kerberos 端口。要允许用户、主机和服务获取 Kerberos 凭据，您可以使用 HTTPS 服务作为通过
HTTPS 端口 443 与 Kerberos 通信的代理。
在 Identity Management(IdM)中，Kerberos 密钥分发中心代理 (KKDCP)提供此功能。
KKDCP 服务器
在 IdM 服务器上，KKDCP 默认启用。如果目录中存在属性和值对 ipaConfigString=kdcProxyEnabled，则 KKDCP 每次启动时会自动启用。在这种情况下，会创建符号链接
/etc/httpd/conf.d/ipa-kdc-proxy.conf。因此，您可以通过检查是否存在符号链接来验证在 IdM 服务器中是否启用了 KKDCP。
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf lrwxrwxrwx. 1 root root 36 Aug 15 09:37 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf
更多详情请见以下示例服务器配置。
例 11.1. 配置 KKDCP 服务器 I
使用以下示例配置，您可以启用 TCP 作为 IdM KKDCP 和 Active Directory 域之间的传输协议，其中使用多个 Kerberos 服务器：
- 在
/etc/ipa/kdcproxy/kdcproxy.conf文件中，将 [global] 部分中的use_dns参数设置为 false ：[global] use_dns = false
- 将代理域信息放在
/etc/ipa/kdcproxy/kdcproxy.conf文件中。对于 [AD.EXAMPLE.COM] realm with proxy，例如：[AD.EXAMPLE.COM] kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88 kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464重要realm 配置参数必须列出由空格分隔的多个服务器，而不是/etc/krb5.conf和kdc.conf，其中某些选项可以多次指定。 - 重启 IdM 服务：
# ipactl restart
例 11.2. 配置 KKDCP 服务器 II
这个示例服务器配置依赖于 DNS 服务记录来查找要与之通信的 AD 服务器。
- 在
/etc/ipa/kdcproxy/kdcproxy.conf文件中，使用 [global] 部分，将use_dns参数设置为 true ：[global] configs = mit use_dns = true
configs参数允许您载入其他配置模块。在这种情况下，配置是从 MITlibkrb5库读取的。 - 可选： 如果您不想使用 DNS 服务记录，请将显式 AD 服务器添加到
/etc/krb5.conf文件的 [realms] 部分。如果带有代理的域为：AD.EXAMPLE.COM，请添加：[realms] AD.EXAMPLE.COM = { kdc = ad-server.ad.example.com kpasswd_server = ad-server.ad.example.com } - 重启 IdM 服务：
# ipactl restart
KKDCP 客户端
客户端系统通过其
/etc/krb5.conf 文件指向 KDC 代理。按照以下步骤访问 AD 服务器。
- 在客户端上，打开
/etc/krb5.conf文件，并将 AD 域的名称添加到 [realms] 部分：[realms] AD.EXAMPLE.COM { kdc = https://ipa-server.example.com/KdcProxy kdc = https://ipa-server2.example.com/KdcProxy kpasswd_server = https://ipa-server.example.com/KdcProxy kpasswd_server = https://ipa-server2.example.com/KdcProxy } - 打开
/etc/sssd/sssd.conf文件，并将 krb5_use_kdcinfo = False 行添加到您的 IdM 域部分：[domain/example.com] krb5_use_kdcinfo = False
- 重启
SSSD服务：# systemctl restart sssd.service
其它资源
- 有关为 Active Directory 域配置 KKDCP 的详情，请参阅在红帽知识库 中将 IPA 服务器配置为用于 AD Kerberos 通信的 KDC 代理。
11.3. 配置 Kerberos 客户端
设置 Kerberos 5 客户端所需的所有是安装客户端软件包，并为每个客户端提供有效的
krb5.conf 配置文件。虽然 ssh 和 slogin 是远程登录到客户端系统的首选方法，但 rsh 和 rlogin 的 Kerberos 感知版本仍然可用，但额外的配置更改。
- 在所有客户端机器上安装
krb5-libs和krb5-workstation软件包。[root@server ~]# yum install krb5-workstation krb5-libs
- 为每个客户端提供有效的
/etc/krb5.conf文件。通常，这与 Kerberos 分发中心(KDC)使用的krb5.conf文件相同。例如：[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM在某些情况下，KDC 只能通过 HTTPS Kerberos 密钥分发中心代理(KKDCP)进行访问。在这种情况下，进行以下更改：- 将 KKDCP 的 URL 而不是主机名分配给 [realms] 部分中的 kdc 和 admin_server 选项：
[realms] EXAMPLE.COM = { kdc = https://kdc.example.com/KdcProxy admin_server = https://kdc.example.com/KdcProxy kpasswd_server = https://kdc.example.com/KdcProxy default_domain = example.com }对于冗余，可使用不同的 KKDCP 服务器多次添加kdc、admin_server 和 kpasswd_server - 在 IdM 客户端上，重启 sssd 服务以使更改生效：
[root@server ~]# systemctl restart sssd
- 要使用 Kerberos 感知的 rsh 和 rlogin 服务，请安装
rsh软件包。 - 在工作站可以使用 Kerberos 验证使用 ssh、rsh 或 rlogin 连接的用户之前，它必须在 Kerberos 数据库中拥有自己的主机主体。sshd、kshd 和 klogind 服务器程序都需要访问主机服务主体的密钥。
- 使用 kadmin，为 KDC 上的 workstation 添加主机主体。本例中的实例是 workstation 的主机名。使用 kadmin 的addprinc 命令的 -randkey 选项来创建主体，并为它分配一个随机键：
addprinc -randkey host/server.example.com
- 通过在 workstation 本身上运行 kadmin 并使用 ktadd 命令，为 workstation 提取密钥。
ktadd -k /etc/krb5.keytab host/server.example.com
- 要使用其他 Kerberos 感知的网络服务，请安装 krb5-server 软件包并启动服务。Kerberos 感知服务列在 表 11.3 “通用 Kerberos 感知服务” 中。
表 11.3. 通用 Kerberos 感知服务
| 服务名称 | 使用信息 |
|---|---|
| ssh | 如果客户端和服务器的配置都启用了 GSSAPI Authentication，OpenSSH 使用 GSS-API 对用户进行身份验证。如果客户端还启用了 GSSAPIDelegateCredentials，该用户的凭证将在远程系统上可用。OpenSSH 还包含 sftp 工具，它为 SFTP 服务器提供类似于 FTP 的接口，并且可以使用 GSS-API。 |
| IMAP |
如果
cyrus-imap 软件包也安装了 cyrus-sasl-gssapi 软件包，则使用 Kerberos 5。cyrus-sasl-gssapi 软件包包含支持 GSS-API 身份验证的 Cyrus SASL 插件。只要 cyrus 用户能够在 /etc/krb5.keytab 中找到正确的密钥，并且主体的 root 设置为 imap （使用 kadmin创建），grus IMAP 可以正常工作。
cyrus-imap 的一个替代方案可在 dovecot 软件包中找到，该软件包也包含在 Red Hat Enterprise Linux 中。此软件包包含 IMAP 服务器，但目前不支持 GSS-API 和 Kerberos。
|
11.4. 为智能卡设置 Kerberos 客户端
智能卡可以和 Kerberos 一起使用，但它需要额外的配置才能识别智能卡上的 X.509(SSL)用户证书：
- 安装所需的 PKI/OpenSSL 软件包以及其他客户端软件包：
[root@server ~]# yum install krb5-pkinit [root@server ~]# yum install krb5-workstation krb5-libs
- 编辑
/etc/krb5.conf配置文件，将公钥基础架构(PKI)的参数添加到配置的 [realms] 部分。pkinit_anchors参数设置 CA 证书捆绑包文件的位置。[realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com ... pkinit_anchors = FILE:/usr/local/example.com.crt } - 将 PKI 模块信息添加到用于智能卡验证的 PAM 配置(
/etc/pam.d/smartcard-auth)和系统身份验证(/etc/pam.d/system-auth)。要添加到这两个文件中的行如下：auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
如果 OpenSC 模块无法按预期工作，请使用 coolkey 软件包中的模块：/usr/lib64/pkcs11/libcoolkeypk11.so。在这种情况下，请考虑联系红帽技术支持或就该问题发布 Bugzilla 报告。
11.5. 设置跨 Realm Kerberos 信任
Kerberos V5 域是 Kerberos 数据库中在所有连接的主和从设备上定义的一组 Kerberos 主体。如果您希望不同域的主体相互通信，则必须配置跨域 Kerberos 信任关系。
许多 Linux 环境以及混合环境已部署 Kerberos 域，以进行单点登录、应用身份验证和用户管理。这使得 Kerberos 成为不同域和混合系统（如 Windows 和 Linux）环境可能常用的集成路径，特别是 Linux 环境没有使用诸如身份管理这样的结构化域配置。
11.5.1. 信任关系
信任 意味着一个域中的用户信任访问另一域中的资源，就像他们属于该域一样。这可以通过为两个域共同持有的单一主体创建一个共享密钥。
图 11.2. 基本信任
在 图 11.2 “基本信任” 中，共享主体将属于域 B (krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM)。如果该主体也添加到 Domain A 中，则 Domain A 中的客户端可以访问 Domain B 中的资源。配置的主体存在于两个域中。该共享主体具有三个特征：
- 它存在于两个域中。
- 创建密钥时，两个域中都使用相同的密码。
- 密钥具有相同的密钥版本号(
kvno)。
默认情况下 ，跨域信任是单向 的。这个信任不会被自动恢复，以便
B.EXAMPLE.COM 域被信任以向 A.EXAMPLE.COM 域中的服务进行身份验证。要在其他方向建立信任，这两个域都需要共享 krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM 服务的密钥 - 上例中带有反向映射的条目。
个域可以有多个信任关系，它信任的域和它值得信任的域。借助 Kerberos 信任，信任可以在链中流动。如果 Realm A 信任 Realm B 和 Realm B，则 Realm A 也信任 Realm A。信任流向域；这是 传递 信任。
图 11.3. 传输信任
传输信任的方向是 信任流。必须定义信任流，首先识别服务所属的域，然后确定客户端必须联系才能访问该服务的域。
Kerberos 主体名称的结构为 service/hostname@REALM 格式。服务 通常是一个协议，如 LDAP、IMAP、HTTP 或主机。hostname 是主机系统的完全限定域名，REALM 则是 它所属的 Kerberos 域。Kerberos 客户端通常使用主机名或 DNS 域名进行 Kerberos 域映射。此映射可以是显式或隐式的。显式映射使用
/etc/krb5.conf 文件的 [domain_realm] 部分。通过隐式映射，域名将转换为大写；然后，转换的名称假定为要搜索的 Kerberos 域。
遍历信任时，Kerberos 假定每个域的结构与具有根域和子域的分层 DNS 域类似。这意味着信任可以流向共享的根用户。每个步骤或 跃点 都具有共享密钥。在 图 11.4 “同一域中的信任” 中，SALES.EXAMPLE.COM 共享带有 EXAMPLE.COM 的密钥，EXAMPLE.COM 与 EVERYWHERE.EXAMPLE.COM 共享一个密钥。
图 11.4. 同一域中的信任
客户端将域名视为 DNS 名称，并且通过剥离其自身域名的元素来确定其信任路径，直至到达根名称。然后开始前置名称，直到到达服务的域。
图 11.5. 相同域中子/优先级信任
信任是传递的本质。SITE.SALES.EXAMPLE.COM 只有一个共享密钥，带有 SALES.EXAMPLE.COM。但因为存在一系列较小的信任关系，因此存在一个很大的信任流，允许信任从 SITE.SALES.EXAMPLE.COM 到 EVERYWHERE.EXAMPLE.COM。
这种信任流程甚至可以在域级别上创建共享密钥，从而完全不同的域之间，其中站点没有共同后缀。
图 11.6. 不同域的信任
[capaths] 部分
也可以通过明确定义流来减少跃点数和表示非常复杂的信任流。
/etc/krb5.conf 文件的 [capaths] 部分定义了不同域之间的信任流。
[capaths] 部分的格式相对简单：每个域都有一个主条目，其中客户端具有主体，然后在每个 realm 部分中是客户端必须获取凭证的中间域列表。
例如，
[capaths] 可用于指定以下用于获取凭证的进程：
- 使用 Realm A 的凭据，客户端从 KDC 域 A 获取
krbtgt/A@Aticket。使用此票据，然后要求提供krbtgt/B@A票据。KDC of Realm A 发布的krbtgt/B@Aticket 是一个跨域票据授予票据。它允许客户端向 Realm B 的 KDC 寻求 Realm B 服务主体的票据。 - 使用
krbtgt/B@A票据时，客户端会要求提供krbtgt/C@B跨域票据。 - 使用 KDC Realm B 发布的
krbtgt/C@Bticket，客户端会要求提供krbtgt/D@C跨域票据。 - 当 KDC 由 Realm C 签发的
krbtgt/D@Cticket 时，客户端会询问 KDC D 以获得 Realm D 的票据，以便在 Realm D 中进入服务主体。
之后，凭据缓存包含
krbtgt/A@A、krbtgt/B@A、krbtgt/C@B、krbtgt/D@C 以及 service/hostname@D 的票据。要获得 service/hostname@D ticket，需要获取三个中间跨域票据。
有关
[capaths] 部分的详情，包括 [capaths] 配置示例，请参阅 krb5.conf(5) man page。
11.5.2. 设置 Realm Trust
在本例中，Kerberos 域是 A.EXAMPLE.COM 和 B.EXAMPLE.COM。
使用 kadmin 为 A 域中 B 域的共享主体创建条目。
[root@server ~]# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit
这意味着 A realm 将信任 B 主体。
重要
建议您为跨域主体选择非常强大的密码。与许多其他密码不同，用户可以如此频繁地在一天中多次提示用户，系统不会要求您频繁地请求输入跨域主体的密码，这就是为什么它不需要易于记忆的原因。
要建立双向信任，请按照相反的方式创建主体。使用 kadmin 为 B realm 中的 A 域创建主体。
[root@server ~]# kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created. quit
使用 get_principal 命令来验证这两个条目是否具有匹配的密钥版本号(
kvno 值)和加密类型。
重要
一个常见，但不正确的情况是管理员尝试使用 add_principal 命令的
-randkey 选项来分配随机密钥，而不是密码，从第一个域的数据库中转储新条目，并将它导入到第二个域。除非域数据库的主密钥相同，否则这将不起作用，因为数据库转储中包含的密钥本身将使用主密钥进行加密。
第 12 章 使用 certmonger
管理计算机身份验证的一部分是管理计算机证书。
certmonger 服务管理应用程序的证书生命周期，如果正确配置，则可以与证书颁发机构(CA)一起工作以续订证书。
certmonger 守护进程及其命令行客户端简化了生成公钥/私钥对、创建证书请求以及向 CA 提交请求以签名的过程。certmonger 守护进程监控证书过期，并可续订即将过期的证书。certmonger 监控的证书在存储在可配置的目录中的文件中跟踪。默认位置为 /var/lib/certmonger/requests。
注意
certmonger 守护进程无法撤销证书。证书只能由相关证书颁发机构撤销，该认证机构需要使证书无效并更新其证书撤销列表。
12.1. 证书和证书颁发机构
默认情况下，certmonger 可以自动获取与证书使用的颁发机构源不同的三类证书：
- 自签名证书生成自签名证书不会涉及任何 CA，因为每个证书都是使用证书本身的密钥签名的。验证自签名证书的软件需要指示其直接信任该证书才能进行验证。要获取自签名证书，请运行 selfsign-getcert 命令。
- 作为 Red Hat Enterprise Linux IdM 的一部分来自 Dogtag 证书系统 CA 的证书要使用 IdM 服务器获取证书，请运行 ipa-getcert 命令
- 由系统中存在本地 CA 签名的证书验证由本地签名人签名的证书的软件需要指示其信任来自本地签名人的证书，以便验证它们。要获取本地签名的证书，请运行 local-getcert 命令。
其他 CA 也可以使用 certmonger 来管理证书，但必须通过创建特殊的 CA 帮助程序 来添加支持到 certmonger。有关如何创建 CA 帮助程序的更多信息，请参阅 certmonger 项目文档，网址为 https://pagure.io/certmonger/blob/master/f/doc/submit.txt。
12.2. 使用 certmonger 请求自签名证书
要请求带有
certmonger 的证书，请使用 getcert 请求 工具。
证书和密钥以纯文本文件存储在本地，其扩展为
.pem 或 NSS 数据库中，由证书 nickname 标识。在请求证书时，请求应标识存储证书的位置和证书的 nickname。例如：
[root@server ~]# selfsign-getcert request -d /etc/pki/nssdb -n Server-Cert
/etc/pki/nssdb 文件是全局 NSS 数据库，Server-Cert 是这个证书的 nickname。证书别名在此数据库中必须是唯一的。
您可以向 命令提供用于生成证书的选项因您请求的证书类型、最终证书所需的配置以及其他设置而异：
- 如果密钥对已存在，R 会在过期日期关闭
时自动续订证书。默认使用这个选项。 -f将证书存储在给定文件中。-K将密钥存储在给定文件中，或者如果密钥文件已存在，则使用 文件中的密钥。-K提供将使用证书的 Kerberos 主体名称；当从 IdM 服务器请求证书时，需要-K，并在请求自签名证书或本地签名证书时可选-n给出主题名称。-d 请求将证书中包含的 DNS 域名作为subjectAltName值。-u设置扩展密钥使用标志。-a 请求证书中包含的 IP 地址作为subjectAltName值。-I为任务设置名称。certmonger使用这个名称来引用存储位置和请求选项的组合，它也显示在 getcert list 命令的输出中。如果没有指定这个选项，certmonger会为任务分配自动生成的名称。
真正的 CA（如 IdM 中的 CA）可以忽略您使用
-K、-N、- D、- U 和 -A 选项在签名请求中指定的任何内容。例如，IdM 需要 -K 和 -N 同意本地主机名。另一方面，使用 selfsign-getcert 和 local-getcert 命令生成的证书会同意您指定的选项，因为这些命令不会强制执行任何策略。
例 12.1. 使用 certmonger 作为服务
[root@server ~]# selfsign-getcert request -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth
12.3. 通过 SCEP 请求 CA 签名证书
简单证书注册协议(SCEP)通过 CA 自动和简化证书管理流程。它允许客户端直接从 CA 的 SCEP 服务请求和通过 HTTP 检索证书。此过程由一次性 PIN 保护，该 PIN 通常仅在有限时间内有效。
以下示例将 SCEP CA 配置添加到
certmonger 中，请求新证书，并将其添加到本地 NSS 数据库中。
- 将 CA 配置添加到
certmonger：[root@server ~]# getcert add-scep-ca -c CA_Name -u SCEP_URL
- -c: CA 配置的强制别名。稍后可以将相同的值传递给其他 getcert 命令。
- -u: 服务器的 SCEP 接口的 URL。
- 使用 HTTPS URL 时强制参数：-r CA_Filename: SCEP 服务器 CA 证书的 PEM 格式的副本的位置，用于 HTTPS 加密。
- 验证 CA 配置是否已成功添加：
[root@server ~]# getcert list-cas -c CA_Name CA 'CA_Name': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7 SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279当 CA 证书指纹通过 SCEP 检索并显示在命令输出中时，CA 配置已成功添加。在通过未加密 HTTP 访问服务器时，手动将thumbprint 与 SCEP 服务器中显示的服务器进行比较，以防止 Man-in-the-middle 攻击。 - 从 CA 请求证书：
[root@server ~]# getcert request -I Task_Name -c CA_Name -d /etc/pki/nssdb -n Certificate_Name -N cn="Subject Name" -L one-time_PIN
- -i: 任务的名称。稍后可以将相同的值传递给 getcert list 命令。
- -c: 将请求提交到的 CA 配置。
- -d: 带有 NSS 数据库的目录，以存储证书和密钥。
- -n: 证书 Nickname，在 NSS 数据库中使用。
- -n: CSR 中的主题名称。
- -L: CA 发布的时间限制一次性 PIN。
- 提交请求后，您可以验证证书是否已签发并正确存储在本地数据库中：
[root@server ~]# getcert list -I TaskName Request ID 'Task_Name': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4 CA: AD-Name issuer: CN=windows-CA,DC=ad,DC=example,DC=com subject: CN=Test Certificate expires: 2018-05-06 10:28:06 UTC key usage: digitalSignature,keyEncipherment eku: iso.org.dod.internet.security.mechanisms.8.2.2 certificate template/profile: IPSECIntermediateOffline pre-save command: post-save command: track: yes auto-renew: yes状态 MONITORING 表示成功检索发布的证书。getcert-list (1) 手册页列出了其他可能的状态及其含义。
12.4. 在 NSS 数据库中存储证书
默认情况下，certmonger 使用
.pem 文件来存储密钥和证书。要在 NSS 数据库中存储密钥和证书，请使用您用于请求证书的命令指定 -d 和 -n。
-d设置安全数据库位置-n指定用于 NSS 数据库中证书的证书别名
注意
使用
-d 和 -n 选项，而不是提供 .pem 文件的 -f 和 -k 选项。
例如：
[root@server ~]# selfsign-getcert request -d /export/alias -n ServerCert ...
使用 ipa-getcert 和 local-getcert 请求证书允许您指定另外两个选项：
-f 提供要存储 CA 证书的文件。-a提供要存储 CA 证书的 NSS 数据库的位置。
注意
如果您使用 selfsign-getcert 请求证书，则不需要指定
-F 和 -a 选项，因为生成自签名证书不会涉及任何 CA。
提供
-F 选项、-a 选项，或带有 local-getcert 选项，允许您获取所需的 CA 证书副本，以便验证本地签名者发布的证书。例如：
[root@server ~]# local-getcert request -F /etc/httpd/conf/ssl.crt/ca.crt -n ServerCert -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key
12.5. 使用 certmonger 跟踪证书
Certmonger 可以监控证书的过期日期，并在其有效期结束时自动续订证书。要以这种方式跟踪证书，请运行 getcert start-tracking 命令。
注意
您不需要在运行 getcert 请求后运行 getcert start-tracking，因为 getcert request 命令默认会自动跟踪和更新请求的证书。当您已通过其他过程获取密钥和证书时，getcert start-tracking 命令适用于以下情况，因此您必须手动指示
certmonger 启动跟踪。
getcert start-tracking 命令有几个选项：
- 如果密钥对已存在，R 会在过期日期关闭
时自动续订证书。默认使用这个选项。 -I为跟踪请求设置名称。certmonger使用这个名称来引用存储位置和请求选项的组合，它也显示在 getcert list 命令的输出中。如果没有指定这个选项，certmonger会为任务分配自动生成的名称。
[root@server ~]# getcert start-tracking -I cert1-tracker -d /export/alias -n ServerCert
要取消证书的跟踪，请运行 stop-tracking 命令。
第 13 章 为单点登录配置应用程序
可以将一些常用应用（如浏览器和电子邮件客户端）配置为使用 Kerberos 票据、SSL 认证或令牌来验证用户。
配置任何应用程序的确切流程取决于该应用程序本身。本章中的示例（Mozilla Thunderbird 和 Mozilla Firefox）旨在让您了解如何配置用户应用以使用 Kerberos 或其他凭据。
13.1. 配置 Firefox 为单点登录使用 Kerberos
Firefox 可以使用 Kerberos 对 Intranet 站点和其他受保护的网站进行单点登录(SSO)。要使 Firefox 使用 Kerberos，必须首先将其配置为将 Kerberos 凭据发送到适当的 KDC。
即使将 Firefox 配置为传递 Kerberos 凭据，它仍需要使用有效的 Kerberos 票据。要生成 Kerberos 票据，请使用 kinit 命令并在 KDC 上提供用户密码。
[jsmith@host ~] $ kinit Password for jsmith@EXAMPLE.COM:
将 Firefox 配置为将 Kerberos 用于 SSO：
- 在 Firefox 的地址栏中，键入
about:config以显示当前配置选项的列表。 - 在 Filter 字段中，键入
negotiate来限制选项列表。 - 双击 network.negotiate-auth.trusted-uris 项。
- 输入要进行身份验证的域的名称，包括上一期间(.)。如果要添加多个域，请在逗号分隔列表中输入它们。
图 13.1. 手动 Firefox 配置
重要
不建议在 Firefox 配置选项中使用 network.negotiate-auth.delegation-uris 条目配置委派，因为这会使每个 Kerberos 感知服务器充当用户。
13.2. Firefox 中的证书管理
要在 Firefox 中管理证书，请打开 证书管理器。
- 在 Mozilla Firefox 中，打开 Firefox 菜单并单击 。
图 13.2. Firefox 首选项
- 打开" 高级 "部分，然后选择 证书 选项卡。
图 13.3. Firefox 中的 certificate 选项卡
- 点 打开 Certificate Manager。
导入 CA 证书：
- 下载 CA 证书并将其保存到您的计算机。
- 在 证书管理器 中，选择" 颁发机构" 选项卡，然后单击 。
图 13.4. 在 Firefox 中导入 CA 证书
- 选择下载的 CA 证书。
设置证书信任关系：
- 在 Certificate Manager 中，在 Authorities 选项卡下，选择适当的证书，再单击 。
- 编辑证书信任设置。
图 13.5. 在 Firefox 中编辑证书信任设置
使用个人证书进行身份验证：
- 在 证书管理器 中，在 Your Certificates 选项卡下，单击 。
图 13.6. 在 Firefox 中导入个人证书以进行身份验证
- 从您的计算机中选择所需的证书。
13.3. 电子邮件客户端中的证书管理
以下示例演示了如何在 Mozilla Thunderbird 电子邮件客户端中管理证书。它代表一般在电子邮件客户端中设置证书的步骤。
- 在 Mozilla Thunderbird 中，打开 Thunderbird 主菜单并选择 Preferences → Account Settings。
- 选择 Security 项，然后单击 以打开 证书管理器。
图 13.7. Thunderbird 中的帐户设置
导入 CA 证书：
- 下载 CA 证书并将其保存到您的计算机。
- 在 证书管理器 中，选择" 颁发机构" 选项卡，然后单击 。
图 13.8. 在 Thunderbird 中导入 CA 证书
- 选择下载的 CA 证书。
设置证书信任关系：
- 在 Certificate Manager 中，在 Authorities 选项卡下，选择适当的证书，再单击 。
- 编辑证书信任设置。
图 13.9. 编辑 Thunderbird 中的证书信任设置
使用个人证书进行身份验证：
- 在 证书管理器 中，在 Your Certificates 选项卡下，单击 。
图 13.10. 在 Thunderbird 中导入个人证书以进行身份验证
- 从您的计算机中选择所需的证书。
- 关闭 证书管理器，再返回到 帐户设置 中的 安全 项目。
- 在表单的 Digital Signing 部分下，单击 以选择要用于签名消息的个人证书。
- 在 Encryption 下，单击 以选择您的个人证书来加密和解密消息。
附录 A. 故障排除
A.1. SSSD 故障排除
A.1.1. 为 SSSD 域设置调试日志
每个域设置自己的调试日志级别。提高日志级别可以提供有关 SSSD 或域配置问题的更多信息。
要更改日志级别，请在
sssd.conf 文件中为每个部分设置 debug_level 参数，以生成额外日志。例如：
[domain/LDAP]
cache_credentials = true
debug_level = 9表 A.1. 调试日志级别
| 级别 | Description |
|---|---|
| 0 | 严重故障.阻止 SSSD 启动或导致 SSSD 停止运行的任何内容。 |
| 1 | 严重故障.没有终止 SSSD 的错误，但表明至少有一个主要功能无法正常工作的错误。 |
| 2 | 严重故障.声明特定请求或操作失败的错误。 |
| 3 | 小故障.这些错误会导致 2 操作失败。 |
| 4 | 配置设置. |
| 5 | 功能数据. |
| 6 | 跟踪操作功能的消息。 |
| 7 | 跟踪内部控制功能的消息。 |
| 8 | 功能内部变量的内容可能比较有趣。 |
| 9 | 极低级别的追踪信息。 |
要在 SSSD 运行时更改 debug 级别，请使用
sss_debuglevel 工具，这是 sssd-tools 软件包的一部分。有关它如何工作的详情请参考 sss_debuglevel man page。
A.1.2. 检查 SSSD 日志文件
SSSD 使用很多日志文件报告其操作的信息，位于
/var/log/sssd/ 目录中。SSSD 为每个域生成日志文件，以及 sssd_pam.log 和 sssd_nss.log 文件。
krb5_child.log: Kerberos 身份验证中涉及的短期帮助程序进程的日志文件ldap_child.log: 与 LDAP 服务器通信的短期帮助程序进程的日志文件selinux_child.log: 检索 SELinux 信息的短期帮助程序进程的日志文件sssd.log： SSSD 与响应器进程通信的日志文件sssd_[domain].log：每个 SSSD 域部分都记录与 LDAP 服务器通信的信息到单独的日志文件sssd_ifp.log: InfoPipe 响应器的日志文件，提供了一个可通过系统总线访问的公共 D-Bus 接口sssd_nss.log：检索用户和组信息的 Name Services Switch (NSS)响应器的日志文件sssd_pac.log: Microsoft Privilege Attribute 证书(PAC)响应器服务的日志文件，该服务定义 SSSD 如何与 Kerberos 一起工作来管理 Active Directory 用户和组sssd_pam.log: 用于可插拔验证模块(PAM)响应器的日志文件sssd_ssh.log: SSH 响应器进程的日志文件
另外，
/var/log/secure 文件记录身份验证失败以及失败的原因。
A.1.3. SSSD 配置的问题
- 问： SSSD 无法启动
- 问： 我没有看到 ID 或组成员 为 entent 组的任何 组。
- 问： 身份验证针对 LDAP 失败。
- 问： 连接到非标准端口上的 LDAP 服务器会失败。
- 问： NSS 无法返回用户信息
- 问： NSS 返回不正确的用户信息
- 问： 为本地 SSSD 用户设置密码会提示输入两次密码
- 问： 在 sssd.conf 文件中正确配置了 Active Directory 身份提供程序，但 SSSD 无法连接到它，并显示 GSS-API 错误。
- 问： 我为中央身份验证配置了 SSSD，但现在我的几个应用程序（如 Firefox 或 Adobe）将不会启动。
- 问： SSSD 显示我删除的自动挂载位置。
问：
SSSD 无法启动
答：
SSSD 要求在守护进程启动前正确设置配置文件，并包含所有需要的条目。
- SSSD 需要至少一个正确配置的域才能启动该服务。如果没有域，尝试启动 SSSD 会返回一个没有配置域的错误：
# sssd -d4 -i [sssd] [ldb] (3): server_sort:Unable to register control with rootdse! [sssd] [confdb_get_domains] (0): No domains configured, fatal error! [sssd] [get_monitor_config] (0): No domains configured.
编辑/etc/sssd/sssd.conf文件并至少创建一个域。 - SSSD 还需要至少一个可用的服务提供商才能启动。如果问题出现在服务供应商配置中，则错误消息表示没有配置服务：
[sssd] [get_monitor_config] (0): No services configured!
编辑/etc/sssd/sssd.conf文件，并至少配置一个服务提供商。重要SSSD 要求在/etc/sssd/sssd.conf文件中的单个services条目中将服务提供商配置为用逗号分开的列表。如果服务在多个条目中列出，则 SSSD 只识别最后一个条目。 - SSSD 还需要正确设置
/etc/sssd/sssd.conf的所有权和权限。如果所有权或权限设置不正确，尝试启动 SSSD 会返回这些错误消息：[sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed. [sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted] [sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted [sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted [sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
设置/etc/sssd/sssd.conf文件的正确所有权和权限：# chmod 600 /etc/sssd/sssd.conf # chown root:root /etc/sssd/sssd.conf
问：
我没有看到 ID 或组成员 为 entent 组的任何 组。
答：
这可能是因为
sssd.conf 的 [domain/DOMAINNAME] 部分中的 ldap_schema 设置不正确。
SSSD 支持 RFC 2307 和 RFC 2307bis 模式类型。默认情况下，SSSD 使用更常见的 RFC 2307 模式。
RFC 2307 和 RFC 2307bis 之间的区别在于组成员资格存储在 LDAP 服务器中的方式。在 RFC 2307 服务器中，组成员存储为多值
memberuid 属性，其中包含属于成员的用户名称。在 RFC2307bis 服务器中，组成员存储为多值 member 或 uniqueMember 属性，其中包含属于这个组成员的用户或组群的 DN。RFC2307bis 还允许维护嵌套组。
如果组查找没有返回任何信息：
- 将 ldap_schema 设置为 rfc2307bis。
- Delete
/var/lib/sss/db/cache_DOMAINNAME.ldb. - 重启 SSSD.
如果这不起作用，请将此行添加到
sssd.conf 中：
ldap_group_name = uniqueMember
然后，删除缓存并再次重新启动 SSSD。
问：
身份验证针对 LDAP 失败。
答：
要进行身份验证，SSSD 需要对通信通道进行加密。这意味着，如果
sssd.conf 被配置为通过标准协议(ldap://)连接，它会尝试使用 Start TLS 加密通信频道。如果将 sssd.conf 配置为通过安全协议连接(ldaps://)，则 SSSD 使用 SSL。
这意味着 LDAP 服务器必须配置为在 SSL 或 TLS 中运行。必须为标准 LDAP 端口(389)或在安全 LDAPS 端口(636)上启用 SSL 启用 TLS。对于 SSL 或 TLS，还必须为 LDAP 服务器配置有效的证书信任关系。
无效的证书信任是针对 LDAP 验证最常见的问题之一。如果客户端没有 LDAP 服务器证书的正确信任，则无法验证连接，SSSD 会拒绝发送密码。LDAP 协议要求以纯文本将密码发送到 LDAP 服务器。通过未加密的连接以纯文本形式发送密码是一个安全问题。
如果证书不被信任，则会写入
syslog 消息，表示无法启动 TLS 加密。证书配置可以通过检查除 SSSD 外是否可以访问 LDAP 服务器来测试证书配置。例如，这会测试通过 TLS 连接到 test.example.com 的匿名绑定：
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
如果没有正确配置证书信任，测试会失败并显示以下错误：
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
信任证书：
- 获取用于为 LDAP 服务器证书签名并将其保存到本地系统的证书颁发机构的公共 CA 证书副本。
- 向
sssd.conf文件中添加一行，指向文件系统上的 CA 证书。ldap_tls_cacert = /path/to/cacert
- 如果 LDAP 服务器使用自签名证书，请从
sssd.conf文件中删除 ldap_tls_reqcert 行。此参数指示 SSSD 信任 CA 证书发布的任何证书，这是使用自签名 CA 证书的安全风险。
问：
连接到非标准端口上的 LDAP 服务器会失败。
答：
在强制模式下运行 SELinux 时，必须修改客户端的 SELinux 策略，以通过非标准端口连接到 LDAP 服务器。例如：
# semanage port -a -t ldap_port_t -p tcp 1389
问：
NSS 无法返回用户信息
答：
这通常意味着 SSSD 无法连接到 NSS 服务。
- 确保 NSS 服务正在运行：
# service sssd status Redirecting to /bin/systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 745 (sssd) CGroup: /system.slice/sssd.service ├─745 /usr/sbin/sssd -D -f ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files... ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files └─805 /usr/libexec/sssd/sssd_pam --debug-to-files当 SSSD 处于Active: active (running)状态以及输出包括sssd_nss时，NSS 服务正在运行。 - 如果 NSS 正在运行，请确保在
/etc/sssd/sssd.conf文件的[nss]部分中正确配置了供应商。特别是检查filter_users和filter_groups属性。 - 确保 NSS 包含在 SSSD 使用的服务列表中。
- 检查
/etc/nsswitch.conf文件中的配置。如需更多信息，请参阅 “配置 NSS 服务以使用 SSSD”一节。
问：
NSS 返回不正确的用户信息
答：
如果搜索返回不正确的用户信息，请检查单独的域中是否没有冲突的用户名。当有多个域时，在
/etc/sssd/sssd.conf 文件中将 use_fully_qualified_domains 属性设置为 true。这会区分名称相同的不同域中的不同用户。
问：
为本地 SSSD 用户设置密码会提示输入两次密码
答：
当尝试更改本地 SSSD 用户的密码时，它可能会提示输入两次密码：
[root@clientF11 tmp]# passwd user1000 Changing password for user user1000. New password: Retype new password: New Password: Reenter new Password: passwd: all authentication tokens updated successfully.
这是 PAM 配置不正确的结果。确定在
/etc/pam.d/system-auth 文件中正确配置了 use_authtok 选项。有关正确配置的示例，请参阅 第 7.5.2 节 “配置服务：PAM”。
问：
在
sssd.conf 文件中正确配置了 Active Directory 身份提供程序，但 SSSD 无法连接到它，并显示 GSS-API 错误。
答：
SSSD 只能使用其主机名连接到 Active Directory 供应商。如果没有指定主机名，SSSD 客户端无法将 IP 地址解析到主机，身份验证会失败。
例如，使用这个配置：
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False
SSSD 客户端返回这个 GSS-API 失败，身份验证请求会失败：
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address)]
要避免这个错误，将
ad_server 设置为 Active Directory 主机的名称，或使用 _srv_ 关键字使用 DNS 服务发现，如 第 7.4.3 节 “配置 DNS 服务发现” 所述。
问：
我为中央身份验证配置了 SSSD，但现在我的几个应用程序（如 Firefox 或 Adobe）将不会启动。
答：
即使在 64 位系统中，32 位应用程序也需要 32 位版本的 SSSD 客户端库才能访问密码和身份缓存。如果 32 位版本的 SSSD 不可用，但系统被配置为使用 SSSD 缓存，则 32 位应用程序可能无法启动。
例如，Firefox 可能会因为 permission denied 错误而失败：
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied 2: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied)
对于 Adobe Reader，错误显示当前系统用户没有被识别：
[jsmith@server ~]$ acroread (acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (366)
其他应用可能会显示类似的用户或权限错误。
问：
SSSD 显示我删除的自动挂载位置。
答：
自动挂载位置的 SSSD 缓存会保留，即使该位置随后被更改或删除。在 SSSD 中更新 autofs 信息：
- 删除 autofs 缓存，如 第 A.1.4 节 “用户在 UID 或 GID 更改后无法登录” 所述。
- 重启 SSSD：
# systemctl restart sssd
A.1.4. 用户在 UID 或 GID 更改后无法登录
更改用户或组群 ID 后，SSSD 会阻止用户登录。
这意味着：
SSSD 根据用户 ID(UID)和组 ID(GID)识别用户和组。当现有用户或组的 UID 或 GID 发生变化时，SSSD 不识别该用户或组。
解决此问题：
使用
sss_cache 程序清除 SSSD 缓存：
- 确保已安装 sssd-tools。
- 要清除特定用户的 SSSD 缓存，并让缓存记录的其余部分保持不变：
# sss_cache --user user_name
清除整个域的缓存：# sss_cache --domain domain_name
实用程序使 SSSD 缓存中的记录无效，用于用户、组或域。之后，SSSD 从身份提供程序检索记录以刷新缓存。
有关
sss_cache 的详情，请查看 sss_cache(8) man page。
A.1.5. SSSD 控制和状态实用程序
SSSD 提供 sssctl 工具，以获取状态信息，在故障排除期间管理数据文件，以及其他与 SSSD 相关的任务。
- 要使用 sssctl，请安装 sssd-tools 软件包：
[root@server ~]# yum install sssd-tools
- sssctl 的一些选项使用 SSSD InfoPipe 响应器。要启用它，请将
ifp添加到/etc/sssd/sssd.conf的services选项中：[sssd] services = nss, sudo, pam, ssh, ifp - 重启 SSSD：
[root@server ~]# systemctl restart sssd.service
A.1.5.1. SSSD 配置验证
sssctl config-check 命令对 SSSD 配置文件执行静态分析。这可让您在重启 SSSD 前验证
/etc/sssd/sssd.conf 文件和 /etc/sssd/conf.d VRF 文件接收报告。
该命令对 SSSD 配置文件执行以下检查：
- 权限
- 所有者和组所有者必须设置为
root:root，权限设为600。 - 文件名
/etc/sssd/conf.d/中的文件名必须使用后缀.conf，而不能以句点（隐藏文件）开头。- 拼写错误
- 部分和选项名称中将检查排字错误。请注意，值不会被检查。
- 选项
- 选项必须放在正确的部分中。
要验证配置，请运行：
# sssctl config-check Issues identified by validators: 3 [rule/allowed_sections]: Section [paM] is not allowed. Check for typos. [rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos. [rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos. Messages generated during configuration merging: 2 File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping. File configuration.conf.disabled did not match provided patterns. Skipping. Used configuration snippet files: 1 /etc/sssd/conf.d/sample.conf
A.1.5.2. 显示用户数据
sssctl user-checks 命令有助于调试使用 SSSD 作为用户查找、身份验证和授权的后端的问题。命令可显示通过 NSS 和 D-Bus 界面的 InfoPipe 响应器提供的用户数据。显示的数据显示用户是否被授权使用
system-auth PAM 服务登录。
例如，显示
admin 用户的用户数据：
# sssctl user-checks admin user: admin action: acct service: system-auth SSSD nss user lookup result: - user name: admin - user id: 1194200000 - group id: 1194200000 - gecos: Administrator - home directory: /home/admin - shell: /bin/bash SSSD InfoPipe user lookup result: - name: admin - uidNumber: 1194200000 - gidNumber: 1194200000 - gecos: Administrator - homeDirectory: /home/admin - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env -
有关更多选项，请查看 sssctl user-checks --help 命令的输出。
A.1.5.3. 域信息
域状态显示域 SSSD 访问的列表，并可让您检索其状态。
- 列出 SSSD 内所有可用域，包括可信域：
[root@server ~]# sssctl domain-list idm.example.com ad.example.com
- 检索域 idm.example.com 的状态：
[root@server ~]# sssctl domain-status idm.example.com Online status: Online
A.1.5.4. 缓存的条目信息
sssctl 命令允许您检索有关缓存条目的信息，以调查和调试与缓存相关的身份验证问题。
要查询用户帐户
admin 的缓存信息，请运行：
[root@server ~]# sssctl user-show admin Name: admin Cache entry creation date: 07/10/16 16:09:18 Cache entry last update time: 07/14/16 10:13:32 Cache entry expiration time: 07/14/16 11:43:32 Initgroups expiration time: Expired Cached in InfoPipe: No
要查询组或网络组的缓存信息，请使用：
[root@server ~]# sssctl group-show groupname [root@server ~]# sssctl netgroup-show netgroupname
A.1.5.5. 截断日志文件
调试问题时，您可以使用 sssctl logs-remove 截断
/var/log/sssd/ 目录中的所有 SSSD 日志文件，以仅捕获新创建的条目。
[root@server ~]# sssctl logs-remove Truncating log files...
A.1.5.6. 删除 SSSD 缓存
要删除 SSSD 缓存数据库文件，s ctl 命令提供
remove-cache 选项。在删除数据库之前，命令会自动创建备份。
使用以下命令备份所有本地数据并删除 SSSD 缓存：
[root@server ~]# sssctl cache-remove SSSD must not be running. Stop SSSD now? (yes/no) [yes] Creating backup of local data... Removing cache files... SSSD needs to be running. Start SSSD now? (yes/no) [yes]
注意
备份仅将本地数据（如本地覆盖）存储在
/var/lib/sss/backup/ 目录中。
要自动导入备份的内容，请运行 sssctl restore-local-data。
A.1.5.7. 获取 LDAP 组获取长信息
涉及查找 LDAP 组信息的操作需要非常长，特别是在有大型组或嵌套组的情况下。
这意味着：
默认情况下，LDAP 组信息查找会返回组的所有成员。对于涉及大型组或嵌套组的操作，返回所有成员会使进程更长。
解决此问题：
评估用户是否属于某个组时，不会使用组查找返回的成员资格列表。要提高性能，特别是身份查找，请禁用组成员资格查找：
- 打开
/etc/sssd/sssd.conf文件： - 在
[domain]部分中，将ignore_group_members选项设置为true。[domain/domain_name] [... file truncated ...]
ignore_group_members = true
注意
当部署涉及具有 compat 树的 IdM 服务器时，不应该将此选项设置为
true。
A.2. 使用 SSSD 和 sudo 调试日志进行故障排除
A.2.1. SSSD 和 sudo 调试日志记录
通过 debug 日志功能，您可以记录有关 SSSD 和 sudo 的额外信息。
sudo 调试日志文件
启用 sudo 调试：
- 将以下行添加到
/etc/sudo.conf中：Debug sudo /var/log/sudo_debug.log all@debug Debug sudoers.so /var/log/sudo_debug.log all@debug
- 以您要调试的用户身份运行 sudo 命令。
/var/log/sudo_debug.log 文件会自动创建，并提供回答问题的详细信息，例如：
- 运行 sudo 命令时，用户和环境有哪些信息？
sudo[22259] settings: debug_flags=all@debug sudo[22259] settings: run_shell=true sudo[22259] settings: progname=sudo sudo[22259] settings: network_addrs=192.0.2.1/255.255.255.0 fe80::250:56ff:feb9:7d6/ffff:ffff:ffff:ffff:: sudo[22259] user_info: user=user_name sudo[22259] user_info: pid=22259 sudo[22259] user_info: ppid=22172 sudo[22259] user_info: pgid=22259 sudo[22259] user_info: tcpgid=22259 sudo[22259] user_info: sid=22172 sudo[22259] user_info: uid=10000 sudo[22259] user_info: euid=0 sudo[22259] user_info: gid=554801393 sudo[22259] user_info: egid=554801393 sudo[22259] user_info: groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670 sudo[22259] user_info: cwd=/ sudo[22259] user_info: tty=/dev/pts/1 sudo[22259] user_info: host=client sudo[22259] user_info: lines=31 sudo[22259] user_info: cols=237
- 哪个数据源用于获取 sudo 规则？
sudo[22259] <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss
- SSSD 插件以以下行开头：
sudo[22259] <- sudo_sss_open @ ./sssd.c:305 := 0
- SSSD 返回了多少条规则？
sudo[22259] Received 3 rule(s)
- 规则是否匹配？
sudo[22259] sssd/ldap sudoHost 'ALL' ... MATCH! sudo[22259] <- user_in_group @ ./pwutil.c:1010 := false
SSSD 调试日志文件
启用 SSSD 调试：
- 将
debug_level选项添加到/etc/sssd部分：/sssd.conf文件的[sudo]和 [domain/domain_name][domain/domain_name] debug_level = 0x3ff0 ... [sudo] debug_level = 0x3ff0
- 重启 SSSD：
# systemctl restart sssd
- 运行 sudo 命令，将调试信息写入日志文件。
创建以下日志文件：
- 域日志文件：
/var/log/sssd/sssd_domain_name.log - 这个日志文件可帮助您回答如下问题：
- SSSD 返回了多少条规则？
[sdap_sudo_refresh_load_done] (0x0400): Received 4-rules rules
- SSSD 从服务器下载了哪些 sudo 规则？
[sssd[be[LDAP.PB]]] [sysdb_save_sudorule] (0x0400): Adding sudo rule demo-name
- 匹配规则是否存储在缓存中？
[sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache
- 哪个过滤器用于从服务器下载规则？
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=client.example.com)(sudoHost=client)(sudoHost=192.0.2.1)(sudoHost=192.0.2.0/24)(sudoHost=2620:52:0:224e:21a:4aff:fe23:1394)(sudoHost=2620:52:0:224e::/64)(sudoHost=fe80::21a:4aff:fe23:1394)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=example,dc=com]
使用此过滤器查找 IdM 数据库中的规则：# ldapsearch -x -D "cn=Directory Manager" -W -H ldap://server.example.com -b dc=example,dc=com '(&(objectClass=sudoRole)...)'
- sudo 响应器日志文件：
/var/log/sssd/sssd_sudo.log - 这个日志文件可帮助您回答如下问题：
- SSSD 返回了多少条规则？
[sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 4-rules rules for [user@idm.example.com]
- 哪个过滤器用于搜索 SSSD 的缓存？
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user)(sudoUser=#10001)(sudoUser=%group-1)(sudoUser=%user)(sudoUser=+*)))]
- 如何查找从 SSSD 缓存返回的规则？使用以下过滤器查找规则：
# ldbsearch -H /var/lib/sss/db/cache_domain_name.ldb -b cn=sysdb '(&(objectClass=sudoRule)...)'
注意ldbsearch工具包含在 ldb-tools 软件包中。
A.3. Firefox Kerberos 配置故障排除
如果 Kerberos 身份验证不起作用，请为身份验证过程打开详细日志记录。
- 关闭 Firefox 的所有实例。
- 在命令提示符中，导出
NSPR_LOG_*变量的值：export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
- 从该 shell 重新启动 Firefox，再访问失败 Kerberos 身份验证的网站。
- 检查
/tmp/moz.log文件中是否有消息中带有 nsNegotiateAuth 的错误消息。
Kerberos 身份验证会出现几个常见错误：
- 没有找到凭证
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found
这意味着没有可用的 Kerberos 票据（这意味着它们已过期或未生成）。要解决这个问题，请运行 kinit 来生成 Kerberos 票据，然后再次打开网站。- 在 Kerberos 数据库中找不到服务器
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database
这意味着浏览器无法联系 KDC。这通常是 Kerberos 配置问题。正确的条目必须位于/etc/krb5.conf文件的 [domain_realm] 部分，以识别域。例如：.example.com = EXAMPLE.COM example.com = EXAMPLE.COM
- 日志中没有错误
- HTTP 代理服务器可以剥离 Kerberos 身份验证所需的 HTTP 标头。尝试使用 HTTPS 连接到站点，这将允许请求通过未修改的传递。
附录 B. 修订历史记录
请注意，修订号与本手册的版本相关，与 Red Hat Enterprise Linux 的版本号无关。
| 修订历史 | |||
|---|---|---|---|
| 修订 7.0-31 | Wed Nov 11 2020 | ||
| |||
| 修订 7.0-30 | Tue Aug 06 2019 | ||
| |||
| 修订 7.0-29 | Tue Apr 08 2019 | ||
| |||
| 修订 7.0-28 | Fri Oct 26 2018 | ||
| |||
| 修订 7.0-27 | Mon Jun 25 2018 | ||
| |||
| 修订 7.0-26 | Tue Apr 10 2018 | ||
| |||
| 修订 7.0-25 | Mon Mar 19 2018 | ||
| |||
| 修订 7.0-24 | Mon Feb 12 2018 | ||
| |||
| 修订 7.0-23 | Mon Jan 29 2018 | ||
| |||
| 修订 7.0-22 | Mon Dec 4 2017 | ||
| |||
| 修订 7.0-21 | Mon Nov 20 2017 | ||
| |||
| 修订 7.0-20 | Mon Nov 6 2017 | ||
| |||
| 修订 7.0-19 | Mon Aug 14 2017 | ||
| |||
| 修订 7.0-18 | Tue Jul 18 2017 | ||
| |||
| 修订 7.0-17 | Mon Mar 27 2017 | ||
| |||
| 修订 7.0-16 | Mon Feb 27 2017 | ||
| |||
| 修订 7.0-15 | Wed Dec 7 2016 | ||
| |||
| 修订 7.0-14 | Tue Oct 18 2016 | ||
| |||
| 修订 7.0-13 | Wed Jul 27 2016 | ||
| |||
| 修订 7.0-11 | Thu Mar 03 2016 | ||
| |||
| 修订 7.0-10 | Tue Feb 09 2016 | ||
| |||
| 修订 7.0-9 | Thu Nov 12 2015 | ||
| |||
| 修订 7.0-8 | Fri Mar 13 2015 | ||
| |||
| 修订 7.0-6 | Wed Feb 25 2015 | ||
| |||
| 修订 7.0-4 | Fri Dec 05 2014 | ||
| |||
| 修订 7.0-1 | July 16, 2014 | ||
| |||
法律通告
Copyright © 2020 Red Hat, Inc.
本文档由红帽根据 Creati ve Commons Attribution-ShareAlike 3.0 Unported License 许可。如果您发布本文档，或者修改了这个文档，则必须向 Red Hat, Inc. 提供相关版本，并提供原始文档的链接。如果修改文档，则必须删除所有红帽商标。
作为本文档的许可者，红帽可能会放弃强制制执行 CC-BY-SA 第4d 条款，且不声明该条款在适用条款允许的最大限度内有效。
红帽、Red Hat Enterprise Linux、Shadowman 徽标、红帽徽标、JBoss、OpenShift、Fedora、Infinity 徽标和 RHCE 是 Red Hat, Inc. 在美国和其他国家/地区注册的商标。
Linux® 是 Linus Torvalds 在美国和其它国家的注册商标。
Java® 是 Oracle 和/或其附属公司的注册商标。
XFS® 是 Silicon Graphics International Corp. 或其子公司在美国和/或其他国家的商标。
MySQL® 是美国、欧洲联合和其它国家的 MySQL AB 的注册商标。
Node.js® 是 Joyent 的一个官方商标。红帽不正式与官方 Joyent Node.js 开源或商业项目进行正式关联或终止。
OpenStack® Word Mark 和 OpenStack 徽标是 OpenStack Foundation 在美国和其它国家的注册商标/服务标记或商标/服务标记，并与 OpenStack Foundation 的权限一起使用。我们不附属于 OpenStack Foundation 或 OpenStack 社区。
所有其他商标均由其各自所有者所有。
