pam_env.conf 可用于定义每次调用 pam_env 模块时为用户设置的标准化环境。它允许您使用以下语法预设环境变量：

VARIABLE  [DEFAULT=VALUE]  [OVERRIDE=VALUE]

有关 pam_env 如何使用的典型示例就是 DISPLAY 变量的调整，在发生远程登录是该变量会改变。例 3.6 “pam_env.conf”中显示了这一点。

REMOTEHOST  DEFAULT=localhost          OVERRIDE=@{PAM_RHOST}
DISPLAY     DEFAULT=${REMOTEHOST}:0.0  OVERRIDE=${DISPLAY}

第一行将 REMOTEHOST 变量的值设置为 localhost，当 pam_env 不能确定任何其他值时就会使用该值。DISPLAY 变量又包含 REMOTEHOST 的值。/etc/security/pam_env.conf 的注释中提供了更多信息。

pam_mount 用于在登录期间装入用户主目录，以及在注销期间从中心文件服务器用来存放所有用户主目录的环境中卸载这些主目录。使用此方法就无需装入一个完整的 /home 目录（通过该目录可访问所有用户主目录），而是仅装入即将登录的用户的主目录。

安装 pam_mount 后，/etc/security 下会有一个 pam_mount.conf.xml 模板。手册页 man 5 pam_mount.conf 中提供了各个元素的说明。

可以使用 YaST 完成此功能的基本配置。选择网络设置 › Windows 域成员资格 › 专家设置以添加文件服务器。请参见Book “储存管理指南”, Chapter 20 “Samba”, Section 20.5 “配置客户端”。

注意：LUKS2 支持

cryptsetup 2.0 中已添加了 LUKS2 支持；从 SUSE Linux Enterprise Server12 SP3 开始，SUSE Linux Enterprise Server 在 pam_mount 中包含了 LUKS2 支持。

可以在 pam_limits 模块将会读取的 limits.conf 中基于用户或组设置系统限制。该文件可让您设置硬限制（即不能超出的限制）和软限制（即可以暂时超出的限制）。有关语法和选项的详细信息，请参见 /etc/security/limits.conf 中的注释。

要使用 YaST 管理 NIS 服务器功能，请以 root 身份运行 zypper in yast2-nis-server 命令来安装 yast2-nis-server 软件包。要为网络配置 NIS 主服务器，请按如下所示继续：

要在网络中配置其他 NIS 从属服务器，请按如下所示继续：

运行某个 YaST 身份验证模块后，您可以使用以下命令检查 SSSD 是否正在运行：

root # systemctl status sssd
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Thu 2015-10-23 11:03:43 CEST; 5s ago
   [...]

为了允许用户在身份验证后端不可用时登录，SSSD 将使用其缓存，即使缓存已失效。这种情况会一直持续到后端再次可用。

要使缓存失效，请运行 sss_cache -E（sss_cache 命令是软件包 sssd-tools的一部分）。

要彻底去除 SSSD 缓存，请运行：

tux > sudo systemctl stop sssd
tux > sudo rm -f /var/lib/sss/db/*
tux > sudo systemctl start sssd

您需使用 dscreate 命令来创建新的 389 Directory Server 实例，并使用 dsctl 命令彻底去除这些实例。

可以基于自定义配置文件以及基于自动生成的模板文件这两种方式来配置和创建新实例。对于测试实例，您可以使用自动生成的模板，而无需进行任何更改，不过，对于生产系统，则必须仔细检查该模板并进行任何必要的更改。

然后，您需要设置管理身份凭证，管理用户和组，并配置身份服务。

执行以下步骤可设置一个用于测试和开发的简单实例，并在其中填充少量的示例项。

389 目录服务器由三个主要命令控制：

您可以基于一个简单的自定义配置文件创建新的 389 Directory Server 实例。此文件必须采用 INF 格式，您可以对其随意命名。

默认实例名称为 localhost。创建实例后，便无法更改实例名称。您最好创建自己的实例名称，而不要使用默认名称，这样可避免混淆并更容易理解实例的工作方式。

例 6.2 显示了一个可用于创建新 389 Directory Server 实例的示例配置文件。您可以复制并使用此文件，不过，请务必创建您自己的口令。

如果您忘记了实例的名称，可使用 dsctl 列出所有实例：

tux > /usr/sbin/dsctl -l
slapd-ldap1

您可以使用 dscreate 命令为新 389 Directory Server 实例自动创建模板。这会创建一个无需进行任何更改即可使用的模板，您也可以根据自己的要求更改此模板。所有默认值在模板文件中都有说明，并已注释掉。要进行更改，请取消注释默认值并输入您自己的值。所有选项都有详细的说明。

下面的示例会将模板输出到 stdout：

tux > dscreate create-template

这有助于快速检查模板，但是，您必须创建一个文件用于创建新 389 Directory Server 实例。您可以对此文件随意命名：

tux > dscreate create-template ldap1-template.txt

下面是新文件中的代码段：

# full_machine_name (str)
# Description: Sets the fully qualified hostname (FQDN) of this system. When 
# installing this instance with GSSAPI authentication behind a load balancer, set 
# this parameter to the FQDN of the load balancer and, additionally, set 
# "strict_host_checking" to "false".
# Default value: ldapserver1.test.net
;full_machine_name = ldapserver1.test.net

# selinux (bool)
# Description: Enables SELinux detection and integration during the installation 
# of this instance. If set to "True", dscreate auto-detects whether SELinux is 
# enabled. Set this parameter only to "False" in a development environment.
# Default value: True 
;selinux = True

从中可以了解它是如何根据现有环境自动配置默认值的。按原样使用此文件来创建一个新实例：

tux > sudo dscreate from-file ldap1-template.txt

这会创建一个名为 localhost 的新实例，并在创建后自动启动该实例：

tux > sudo dsctl localhost status
Instance "localhost" is running

使用默认值会创建一个完全可正常运行的实例，不过您也可以更改某些值。

创建实例后，便无法更改实例名称。您最好创建自己的实例名称，而不要使用默认名称，这样可避免混淆并更容易理解实例的工作方式。为此，请取消注释 ;instance_name = localhost 行，并将 localhost 更改为所需的名称。在以下示例中，实例名称为 ldap1。

另一项有用的更改是在新实例中填充示例用户和组。取消注释 ;sample_entries = no，并将 no 更改为 yes。

通过取消注释 ;root_password 并将默认口令替换为您自己的口令来设置口令。

模板不会创建默认后缀，因此您应在 suffix 行中配置自己的后缀，如下例所示：

suffix = dc=ldap1,dc=com

可以使用 dsctl 彻底去除任何实例，然后重新开始创建：

tux > sudo dsctl ldap1 remove --do-it

使用 systemd 管理 389 Directory Server 实例。获取服务器状态：

tux > systemctl status --no-pager --full dirsrv@ldap1.service       
   ● dirsrv@ldap1.service - 389 Directory Server ldap1.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-03-11 08:55:28 PST; 2h 7min ago
    Process: 4451 ExecStartPre=/usr/lib/dirsrv/ds_systemd_ask_password_acl /etc/dirsrv/slapd-ldap1/dse.ldif (code=exited, status=0/SUCCESS)
   Main PID: 4456 (ns-slapd)
     Status: "slapd started: Ready to process requests"
      Tasks: 26
     CGroup: /system.slice/system-dirsrv.slice/dirsrv@ldap1.service
             └─4456 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-ldap1 -i /run/dirsrv/slapd-ldap1.pid

启动和停止服务器：

tux > sudo systemctl start dirsrv@ldap1.service
tux > sudo systemctl stop dirsrv@ldap1.service

有关使用 systemctl 的详细信息，请参见Book “管理指南”, Chapter 15 “systemd 守护程序”。

dsctl 命令还可启动和停止服务器：

tux > sudo dsctl ldap1 status
tux > sudo dsctl ldap1 stop
tux > sudo dsctl ldap1 restart
tux > sudo dsctl ldap1 start

要对 389 Directory Server 进行本地管理，您可以在 /root 目录中创建一个 .dsrc 配置文件，这样 root 和 sudo 用户管理服务器时就不必每运行一条命令都要键入连接细节。例 6.3 显示了在服务器上进行本地管理的示例，其中使用了 ldap1 和 com 作为基本 DN。

创建 /root/.dsrc 文件后，请尝试运行几条管理命令，例如创建新用户（参见第 6.4 节 “管理 LDAP 用户和组”）。

# /root/.dsrc file for administering the ldap1 instance
         
[ldap1] 1

uri = ldapi://%%2fvar%%2frun%%2fslapd-ldap1.socket 2
basedn = dc=ldap1,dc=com
binddn = cn=Directory Manager

OpenLDAP 与 389 Directory Server 的差异相当大，可能需要对迁移进行反复测试和调整。执行快速迁移测试可能会很有帮助，这样可大致了解需要执行哪些步骤才能确保迁移成功。

先决条件:

如果您的 slapd 配置不是动态 ldif 格式，请使用 slaptest 创建动态副本。创建 slapd.d 目录，然后运行以下命令：

tux > sudo slaptest -f /etc/openldap/slapd.conf -F /root/slapd.d

这会生成类似于以下示例的内容：

tux > sudo ls  slapd.d/*
slapd.d/cn=config.ldif

slapd.d/cn=config:
cn=module{0}.ldif  cn=schema.ldif                 olcDatabase={0}config.ldif
cn=schema          olcDatabase={-1}frontend.ldif  olcDatabase={1}mdb.ldif

为每个后缀创建一个 ldif 文件。在以下示例中，后缀为 dc=ldap1,dc=com。如果您使用的是 /etc/openldap/slapd.conf 格式，请运行以下命令创建 ldif 备份文件：

tux > sudo slapcat -f /etc/openldap/slapd.conf -b dc=ldap1,dc=com -l /root/ldap1-com.ldif

对于 /etc/openldap/slapd.d 格式，请使用以下命令：

tux > sudo slapcat -f /etc/openldap/slapd.conf -b dc=ldap1,dc=com -l /root/ldap1-com.ldif

使用 openldap_to_ds 分析配置和文件，并显示迁移计划而不更改任何内容：

tux > sudo openldap_to_ds ldap1 /root/slapd.d ldap1-com.ldif

这会执行试运行，但不更改任何内容。输出如下所示：

Examining OpenLDAP Configuration ...
Completed OpenLDAP Configuration Parsing.
Examining Ldifs ...
Completed Ldif Metadata Parsing.
The following migration steps will be performed:
 * Schema Skip Unsupported Attribute -> otherMailbox (0.9.2342.19200300.100.1.22)
 * Schema Skip Unsupported Attribute -> dSAQuality (0.9.2342.19200300.100.1.49)
 * Schema Skip Unsupported Attribute -> singleLevelQuality (0.9.2342.19200300.100.1.50)
 * Schema Skip Unsupported Attribute -> subtreeMinimumQuality (0.9.2342.19200300.100.1.51)
 * Schema Skip Unsupported Attribute -> subtreeMaximumQuality (0.9.2342.19200300.100.1.52)
 * Schema Create Attribute -> suseDefaultBase (SUSE.YaST.ModuleConfig.Attr:2)
 * Schema Create Attribute -> suseNextUniqueId (SUSE.YaST.ModuleConfig.Attr:3)
[...]
 * Schema Create ObjectClass -> suseDhcpConfiguration (SUSE.YaST.ModuleConfig.OC:10)
 * Schema Create ObjectClass -> suseMailConfiguration (SUSE.YaST.ModuleConfig.OC:11)
 * Database Reindex -> dc=example,dc=com
 * Database Import Ldif -> dc=example,dc=com from example.ldif - excluding entry attributes = [{'structuralobjectclass', 'entrycsn'}]
No actions taken. To apply migration plan, use '--confirm'

以下示例会执行迁移，其输出与试运行后的输出不同：

tux > sudo openldap_to_ds ldap1 /root/slapd.d ldap1-com.ldif --confirm
Starting Migration ... This may take some time ...
migration: 1 / 40 complete ...
migration: 2 / 40 complete ...
migration: 3 / 40 complete ...
[...]
Index task index_all_05252021_120216 completed successfully
post: 39 / 40 complete ...
post: 40 / 40 complete ...
🎉 Migration complete!
----------------------
You should now review your instance configuration and data:
 * [ ] - Create/Migrate Database Access Controls (ACI)
 * [ ] - Enable and Verify TLS (LDAPS) Operation
 * [ ] - Schedule Automatic Backups
 * [ ] - Verify Accounts Can Bind Correctly
 * [ ] - Review Schema Inconistent ObjectClass -> pilotOrganization (0.9.2342.19200300.100.4.20)
 * [ ] - Review Database Imported Content is Correct -> dc=ldap1,dc=com

迁移完成后，openldap_to_ds 会创建必须完成的迁移后任务核对清单。最好记录所有迁移后步骤，以便可以在后期生产过程中再现这些步骤。然后测试客户端和应用程序与迁移后 389 Directory Server 实例的集成。

重要：制定回滚计划

必须制定一个回滚计划，以防发生任何失败。此计划应该定义成功迁移的要素、用于确定哪些方面正常以及哪些方面需要修复的测试、至关重要的步骤、可以推迟的事项、如何确定何时撤消更改、如何在尽量减少服务中断的情况下撤消更改，以及其他哪些团队需要参与迁移。

由于部署的可变性，很难提供成功进行生产迁移的通用方法。一旦您全面测试了迁移过程并确认可以获得较好的结果，就可以采取一些有用的常规步骤：

由于 OpenLDAP 如同一个“零件箱”且高度可自定义，因此无法制定出放之四海皆准的迁移计划。有必要针对 OpenLDAP 和其他集成评估您的当前环境和配置。这包括但不限于：

规划 389 Directory Server 部署的最终大致结果。此项规划包含的内容与上面的列表相同，不过需要将叠加组件替换为插件。评估当前环境并规划您的 389 Directory Server 环境将会是什么样之后，便可以制定迁移计划。建议构建与 OpenLDAP 环境并行的 389 Directory Server 环境，以便可以在两者之间切换。

从 OpenLDAP 迁移到 389 Directory Server 属于单向迁移。两者之间的差异相当大，因此它们不可互操作，并且不存在从 389 Directory Server 到 OpenLDAP 的迁移路径。下表重点指出了两者的主要相似和不同之处。

在首次接触 Kerberos 时，您的操作与在常规网络系统进行的任何登录过程类似。输入您的用户名。这一信息和票据授权服务的名称被发送到身份验证服务器 (Kerberos)。如果身份验证服务器知道您的身份，它会生成一个随机会话密钥，供以后在客户端和票据授权服务器之间使用。身份验证服务器现在将为票据授权服务器准备一个票据。该票据包含以下信息 － 仅认证服务器和票据授权服务器知道的、由会话密钥加密的所有信息：

随后，还是以加密形式将此票据与会话密钥一起发送回客户端，但这次使用的是客户端的私用密钥。只有 Kerberos 和客户端知道此私用密钥，因为它是从您的用户口令派生的。由于客户端已经收到了此响应，计算机将提示您输入口令。此口令被转换为一个密钥，利用它可解密身份验证服务器所发送的包。然后“拆封”此包，并将口令和密钥从工作站的内存中删除。只要没有超过为用于获取其他票据的那个票据指定的有效期，工作站就能证明您的身份。

要从网络中的任何服务器请求服务，客户端应用程序都需要向服务器证明其身份。因此，此应用程序生成一个身份验证器。身份验证器包含以下部分：

所有这些信息都使用客户端为这个特殊服务器接收到的会话密钥进行了加密。用于服务器的身份验证器和票据会被发送到该服务器。该服务器使用自身的会话密钥副本来解密身份验证器，而身份验证器为它提供与请求其服务的客户端相关的全部所需信息，然后服务器将这些信息与票据中包含的信息进行对比。服务器将检查票据和身份验证器是否来自同一客户端。

如果在服务器端没有采取任何安全措施，则这个阶段的过程将成为重放攻击的理想目标。某些人可能试图重发先前从网络上窃取的请求。为防止出现这种情况，服务器将不接受具有先前已收到过的时间戳和票据的任何请求。此外，忽略时间戳与接收请求时的时间相差太大的请求。

Kerberos 身份验证可以双向使用。它不仅可以验证客户端是否为它所声称的客户端，服务器本身也应能够向请求其服务的客户端身份验证自己。因此，它本身会发送身份验证器。它将在客户端的身份验证器中接收的校验和加 1，然后使用它和客户端共享的会话密钥对其加密。客户端将此响应作为对服务器的真实性的校验，然后它们开始协作。

票据每次仅供一个服务器使用。因此，每当您请求另一个服务时，就需要获取一个新票据。Kerberos 实施了一种机制来获取用于各个服务器的票据。这种服务被称为“票据授权服务”。票据授权服务与前面提到的任何服务一样，也使用已介绍过的相同访问协议。当应用程序需要一个尚未请求过的票据时，就会联系票据授权服务器。此请求包含以下部分：

与任何其他服务器一样，票据授权服务器现在将检查票据授权票据和身份验证器。如果确定它们有效，票据授权服务器将构建一个将在原始客户端和新服务器之间使用的新会话密钥。然后构建用于新服务器的票据，其中包含以下信息：

新票据具有一个有效期，该有效期是票据授权票据的剩余有效期，或服务的默认有效期。系统将指派这两个值中较小的一个。客户端会接收票据授权服务发送的此票据和会话密钥。但这一次，响应已通过原始票据授权票据附带的会话密钥加密。当联系新服务时，客户端可以解密此响应而不需要用户的口令。因此，Kerberos 无需烦扰用户就能获取客户端的一个又一个票据。

任何 Kerberos 环境都必须符合以下要求才能完全正常运行：

下图描绘了一个简单的示例网络，其中仅包含构建 Kerberos 基础结构至少所需的组件。根据您的部署大小和拓扑，您的设置可能与此不同。

图 7.1︰ Kerberos 网络拓扑 #

 

提示：配置子网路由

对于类似于图 7.1 “Kerberos 网络拓扑”中所示的设置，需在两个子网（192.168.1.0/24 和 192.168.2.0/24）之间配置路由。有关使用 YaST 配置路由的详细信息，请参见Book “管理指南”, Chapter 19 “基本网络知识”, Section 19.4.1.5 “配置路由”。

Kerberos 安装的域称为领域，通过一个名称（如 EXAMPLE.COM 或简单的 ACCOUNTING）来标识。Kerberos 区分大小写，因此 example.com 实际上是与 EXAMPLE.COM 不同的领域。您可根据自己的偏好选择使用大小写。但通常的做法是使用大写领域名。

使用您的 DNS 域名（或子域，如 ACCOUNTING.EXAMPLE.COM）也是个不错的选择。如下所示，如果将 Kerberos 客户端配置为通过 DNS 来查找 KDC 和其他 Kerberos 服务，则系统管理员的工作就轻松多了。要做到这一点，将领域名设为 DNS 域名的子域会很有帮助。

与 DNS 名称空间不同，Kerberos 是不分级的。因此，如果您有一个名为 EXAMPLE.COM 的领域，该领域包含名为 DEVELOPMENT 和 ACCOUNTING 的两个“子领域”，这些从属领域不会从 EXAMPLE.COM 继承主体。相反，您拥有的是三个独立的领域，并需要为每个领域配置跨领域的身份验证，使一个领域中的用户能够与另一个领域中的服务器或其他用户交互。

为了便于说明，假设您只为整个组织设置一个领域。在本章剩余部分中，将在所有示例中使用领域名 SAMPLE.COM。

要使用 Kerberos，首先需要一台用作密钥分发中心（或简称 KDC）的计算机。这台计算机将储存整个 Kerberos 用户数据库，其中包含口令和所有信息。

KDC 是安全基础设施中最重要的部分 － 如果有人侵入，则 Kerberos 保护的所有用户帐户和基础设施都会受到损害。能够访问 Kerberos 数据库的攻击者可以冒充数据库中的任何主体。所以应尽可能提高此计算机的安全性：

要成功使用 Kerberos，应确保您的组织内的所有系统时钟都在给定范围内同步。这一点非常重要，因为 Kerberos 需要防范重放的身份凭证。攻击者可能会在网络上获取 Kerberos 身份凭证，并再使用它们来攻击服务器。Kerberos 采取多种保护措施进行防范。其中之一是在它们的票据中放入时间戳。如果服务器收到的票据的时间戳与当前时间不同，就会拒绝此票据。

Kerberos 在比较时间戳时允许一定的偏差。但计算机时钟的走时可能非常不准确 — 在一周内快或慢半个小时并不罕见。因此，应对网络上的所有主机进行配置，使它们的时钟与中央时间源同步。

要实现此目的，一种简单的方法就是在一台计算机上安装 NTP 时间服务器，并使所有客户端的时钟与该服务器同步。为此，请在所有这些计算机上以客户端的身份运行 NTP 守护程序 chronyd。KDC 本身也需要与公用时间源同步。由于在此计算机上运行 NTP 守护程序会有安全风险，通过 cron 作业运行 chronyd -q 执行此操作可能是个不错的选择。要将您的机器配置成 NTP 客户端，如Book “管理指南”, Chapter 30 “使用 NTP 同步时间”, Section 30.1 “使用 YaST 配置 NTP 客户端”中概述的那样继续操作。

另一种保护时间服务并仍旧使用 NTP 守护程序的做法是，将一个硬件参考时钟挂接到专用的 NTP 服务器，并将另一个硬件参考时钟挂接到 KDC。

也可以调整 Kerberos 在检查时间戳时所允许的最大偏差。此值（称为时钟扭斜）可以在 krb5.conf 文件中进行设置，请参见第 7.5.6.3 节 “调整时钟偏差”一节。

本节介绍 KDC 的初始配置和安装，包括创建管理主体。此过程包括几个步骤：

[libdefaults]
 dns_canonicalize_hostname = false
 rdns = false
 default_realm = example.com
 ticket_lifetime = 24h
 renew_lifetime = 7d

[realms]
  example.com = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }
 
 [logging]
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 default = SYSLOG:NOTICE:DAEMON

[domain_realm]
 .example.com = example.com
 example.com = example.com

tux > sudo kdb5_util create -r EXAMPLE.COM -s

Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  1
Re-enter KDC database master key to verify:  2

tux > kadmin.local

kadmin> listprincs

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

tux > kadmin.local

kadmin> ank geeko

geeko@EXAMPLE.COM's Password: 1
Verifying password: 2

tux > sudo systemctl start krb5kdc
sudo systemctl start kadmind

tux > sudo systemctl enable krb5kdc kadmind

当已部署好支持基础结构（DNS、NTP）且已配置并启动 KDC 时，请配置客户端计算机。要配置 Kerberos 客户端，请使用下面所述的两种手动方法之一。

在配置 Kerberos 时，可以采用两种方法 — 在 /etc/krb5.conf 文件中进行静态配置或通过 DNS 进行动态配置。采用 DNS 配置时，Kerberos 应用程序会尝试使用 DNS 记录查找 KDC 服务。采用静态配置时，将您的 KDC 服务器的主机名添加到 krb5.conf（并在移动 KDC 或以其他方式重配置领域时更新文件）。

基于 DNS 的配置通常比较灵活，而且每台计算机的配置工作量也少得多，但要求您的领域名与您的 DNS 域相同或是它的子域。通过 DNS 配置 Kerberos 也会产生安全问题：攻击者能够通过 DNS 严重破坏您的基础结构（通过使名称服务器无效、窃取 DNS 记录等），但这最多只会造成拒绝服务攻击。除非在 krb5.conf 中输入 IP 地址而非主机名，否则静态配置也会发生相同的情况。

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

[domain_realm]
.example.com = EXAMPLE.COM
www.example.org = EXAMPLE.COM

_kerberos.www.example.org.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

为了无需直接访问 KDC 控制台即可从 Kerberos 数据库添加和去除主体，请编辑 /var/lib/kerberos/krb5kdc/kadm5.acl 以告知 Kerberos 管理服务器要允许哪些主体执行哪些操作。ACL（访问控制列表）文件可让您以精确的控制度指定特权。有关详细信息，请使用 man 8 kadmind 来参考手册页。

目前请通过在该文件中插入以下一行向您自己授予管理数据库的特权：

geeko/admin              *

请将用户名 geeko 替换为您自己的用户名。重启动 kadmind 以使更改生效。

您现在应该能够使用 kadmin 工具远程执行 Kerberos 管理任务。首先，为您的 admin 角色获得一个票据，并在连接到 kadmin 服务器时使用此票据：

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

使用 getprivs 命令验证您有哪些特权。上面的列表中列出了全部特权。

例如，修改主体 geeko：

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:

kadmin:  getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin:  getprinc geeko
Principal: geeko@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (geeko/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

这将票据的最长生命周期更改为 8 小时。有关 kadmin 命令和可用选项的详细信息，请参见 krb5-doc 软件包或 man 8 kadmin 手册页。

到目前为止，我们仅讨论了用户身份凭证。但与 Keberos 兼容的服务通常也需要将它们自己认证到客户端。因此，对于领域中提供的每个服务，Kerberos 数据库中必须存在特殊的服务主体。例如，如果 ldap.example.com 提供 LDAP 服务，您将需要一个服务主体 ldap/ldap.example.com@EXAMPLE.COM，以使此服务向所有客户端验证身份。

服务主体的命名约定是 SERVICE/HOSTNAME@REALM，其中 HOSTNAME 是主机的完全限定主机名。

有效的服务描述符为：

服务主体类似于用户主体，但存在一些重大差别。用户主体与服务主体之间的主要差别在于，前者的密钥受口令保护。当用户从 KDC 获取票据授权票据时，他们需要键入其口令，以使 Kerberos 能够解密该票据。如果系统管理员大约每 8 小时就必须为 SSH 守护程序获取一次新的票据，将会很不方便。

实际上，用来解密服务主体的初始票据的密钥是由管理员从 KDC 一次性提取的，并储存在名为 keytab 的本地文件中。SSH 守护程序等服务将读取此密钥并在需要时使用它来自动获取新票据。默认 keytab 文件位于 /etc/krb5.keytab 中。

要为 jupiter.example.com 创建主机服务主体，请在您的 kadmin 会话期间输入以下命令：

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

-randkey 标志没有为新主体设置口令，而是指示 kadmin 生成一个随机密钥。之所以在这里使用这个标志，是因为此主体不需要用户交互。它是计算机的一个服务器帐户。

最后，抽取密钥并将其储存在本地 keytab 文件 /etc/krb5.keytab 中。这个文件由超级用户拥有，所以您必须是 root 用户才能在 kadmin shell 中执行以下命令：

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.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/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

完成后，应确保使用 kdestroy 命令销毁通过 kinit 获得的 admin 票据。

警告：不完整的配置会锁定用户

不完整的 Kerberos 配置可能会将您（包括 root 用户）完全锁定在系统之外。要防止出现这种情况，请在根据下面所述将 pam_krb5 模块添加到现有的 PAM 配置文件之后，将 ignore_unknown_principals 指令添加到 pam_krb5 模块。

tux > sudo pam-config --add --krb5-ignore_unknown_principals

这会指示 pam_krb5 模块忽略某些错误，如不忽略，帐户阶段将会失败。

SUSE® Linux Enterprise Server 随附了一个名为 pam_krb5 的 PAM 模块，该模块支持 Kerberos 登录和口令更新。su 等控制台登录应用程序以及 GDM 等图形登录应用程序可以使用此模块。也就是说，在希望用户输入口令后由身份验证应用程序代表其获取初始 Kerberos 票据的所有场合，都可以使用此模块。要为 Kerberos 配置 PAM 支持，请使用下面的命令：

tux > sudo pam-config --add --krb5

上述命令将 pam_krb5 模块添加到现有的 PAM 配置文件，并确保以正确的顺序调用该模块。要精确调整 pam_krb5 的使用方式，请编辑 /etc/krb5.conf 文件并将默认应用程序添加到 PAM。有关详细信息，请使用 man5 pam_krb5 来参考手册页。

pam_krb5 模块的设计特意不用于接受 Kerberos 票据作为部分用户身份验证的网络服务。这一点很特别，后面将会讨论。

OpenSSH 在协议版本 1 和 2 中均支持 Kerberos 身份验证。在版本 1 中，会通过特殊协议消息传输 Kerberos 票据。版本 2 不再直接使用 Kerberos，而是依赖于 GSSAPI，即通用安全服务 API.这是一种不特定于 Kerberos 的编程接口 － 其设计目的是隐藏基础身份验证系统的特性，无论它是 Kerberos、公共密钥认证系统（如 SPKM）还是其他系统。但是，包含的 GSSAPI 库仅支持 Kerberos。

要将 sshd 与 Kerberos 身份验证一起使用，请编辑 /etc/ssh/sshd_config 并设置如下选项：

# These are for protocol version 1
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# These are for version 2 - better to use this
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

然后使用 sudo systemctl restart sshd 重启动您的 SSH 守护程序。

要将 Kerberos 认证与协议版本 2 一起使用，需要在客户端也启用它。此操作可在整个系统范围的配置文件 /etc/ssh/ssh_config 中执行，也可通过编辑 ~/.ssh/config 在每个用户级别上执行。在这两种情况下，均应添加选项 GSSAPIAuthentication yes。

您现在应该能够使用 Kerberos 身份验证进行连接。使用 klist 校验您是否拥有有效票据，然后连接到 SSH 服务器。要强制使用 SSH 协议版本 1，请在命令行上指定选项 -1。

提示：更多信息

文件 /usr/share/doc/packages/openssh/README.kerberos 中详细讨论了 OpenSSH 和 Kerberos 的交互。

提示：协议版本 2 的其他指令

支持 GSSAPIKeyExchange 机制 (RFC 4462)。此指令指定如何交换主机密钥。有关详细信息，请参见 sshd_config 手册页 (man sshd_config)。

Kerberos 提供身份验证，而 LDAP 则用于授权和标识。这两个服务可以配合工作。

为建立安全连接，389 目录服务器支持以不同的方式加密数据：SSL/TLS 连接、启动 TLS 连接和 SASL 身份验证。简单身份验证和安全层 (SASL) 是用于进行身份验证的网络协议。在 SUSE Linux Enterprise Server 中使用的 SASL 实现是 cyrus-sasl。Kerberos 身份验证是通过 GSS-API（常规安全服务 API）执行的，该 API 由 cyrus-sasl-gssapi 软件包提供。389 目录服务器通过 GSS-API 使用 Kerberos 票据对会话进行身份验证和加密数据。

借助 SASL 框架，您可以使用不同的机制向服务器验证用户的身份。在 Kerberos 中，身份验证永远是相互的。这表示您不仅向 389 目录服务器验证了您自己的身份，389 目录服务器本身也向您验证了它的身份。具体而言，这表示您是与所需的服务器而不是攻击者设置的随机服务进行通讯。

为了使 Kerberos 能够绑定到 389 目录服务器，请创建一个主体 ldap/ldap.example.com 并将其添加到 keytab。389 目录服务器用来进行身份验证的身份凭证将由 keytab 提供给其他服务器。389 目录服务器通过 KRB5_KTNAME 环境变量指派 keytab。

tux > kinit geeko@EXAMPLE.COM

tux > ldapwhoami -Y GSSAPI -H ldap://ldapkdc.example.com
dn: uid=testuser,ou=People,dc=example,dc=com
    

sec=sys 与各种 Kerberos 安全级别之间的一个可以察觉到的行为差异与组成员资格相关。在 Unix 和 Linux 中，每个文件系统访问请求都来自某个进程，该进程由特定的用户拥有，并具有特定的组拥有者和多个补充组。对文件的访问权限因拥有者和各个组而异。

在每个请求中，使用 sec=sys 将 user-id、group-id 以及最多包含 16 个补充组的列表发送到服务器。

如果某个用户是 16 个以上的补充组的成员，超额的组将会丢失，并且在正常情况下用户本应可以访问的某些文件可能无法通过 NFS 访问。因此，使用 NFS 的大多数站点会通过某种方法将所有用户限制为最多 16 个补充组。

如果用户运行 newgrp 命令或运行 set-group-id 程序，并且该命令或程序可以更改用户所属的组列表，则这些更改会立即生效，并提供 NFS 上的不同访问权限。

使用 Kerberos 时，请求中不会发送组信息。只会标识用户（使用 Kerberos “主体”），服务器将执行查找来确定该主体的用户 ID 和组列表。这意味着，如果用户是 16 个以上的组的成员，则会使用所有这些组成员资格来确定文件访问权限。但也意味着，如果用户在客户端上以某种方式更改 group-id，服务器将不会注意到这种更改，并且在确定访问权限时也不会将其纳入考量。

通常，在提供对更多组的访问方面所做的改进能够带来真正的好处，而无法更改组所带来的损失不会被注意到，因为这种做法不太常用。不过，考虑使用 Kerberos 的站点管理员应该了解这种差异，并确保它不会真正造成问题。

利用 Kerberos 提高安全性需要使用额外的 CPU 资源来加密和解密消息。需要多少额外的 CPU 资源以及差异是否明显取决于所用的硬件和应用程序。如果服务器或客户端已用尽了可用的 CPU 资源，在从 sec=sys 切换到 Kerberos 时，可能会出现相当严重的性能下降。如果还有富余的 CPU 容量，则这种过渡很可能不会导致任何吞吐量变化。确定使用 Kerberos 所造成的影响大小的唯一方式是在硬件上测试您的负载。

可以减轻负载的配置选项同时也会降低提供的保护质量。sec=krb5 产生的负载应该比 sec=krb5p 要小得多，但如上文所述，它不能提供很高的安全性。类似地，您可以调整可供 Kerberos 从中选择的口令列表，而这可能会改变 CPU 的要求。但是，默认值是经过精心选择的，如未同样经过谨慎考虑，不应更改这些值。

将 NFS 配置为使用 Kerberos 时可能存在的另一个性能问题涉及到 Kerberos 身份验证服务器（称为 KDC 或密钥分发中心）的可用性。

使用 NFS 会增大此类服务器的负载，程度与对任何其他服务使用 Kerberos 时所增大的负载相同。每当给定的用户（Kerberos 主体）与服务建立会话时（例如，通过访问特定 NFS 服务器导出的文件），客户端就需要与 KDC 协商。协商会话密钥后，客户端与服务器在许多个小时内（此时段取决于 Kerberos 配置的细节，具体而言取决于 ticket_lifetime 设置）无需进一步的帮助即可通讯。

最有可能影响 Kerberos KDC 服务器供应的因素是可用性和峰值用量。

与其他核心服务（例如 DNS、LDAP）或类似的名称查找服务一样，使用两个距离每个客户端都比较“近”的服务器能够在资源有限时提供较佳的可用性。Kerberos 允许使用多个具有灵活模型的 KDC 服务器来进行数据库传播，因此，在校园、建筑物甚至机柜周围按需排布服务器的工作相当简单。确保每个客户端都查找附近的 Kerberos 服务器的最佳机制是对每个建筑物（或类似设施）使用水平分割 DNS 来从 DNS 服务器获取不同的细节。如果这种方法不可行，也可采用在不同的位置管理不同的 /etc/krb5.conf 文件这种替代做法。

由于对 Kerberos KDC 的访问并不频繁，只有在高峰时间，负载才可能会成为一个问题。如果数千人都在 9:00 到 9:05 登录，则服务器每分钟收到的请求数就会比在午夜收到的要多得多。Kerberos 服务器上的负载可能会超过 LDAP 服务器，但不会有数量级的差异。较为合理的准则是采用供应 LDAP 复本的相同方式来供应 Kerberos 复本，然后监视性能以确定需求是否超过容量。

Kerberos KDC 的一个不容易分发的服务是更新处理，例如口令更改和新用户的创建。这些操作必须在单个主 KDC 上进行。

这些更新不太可能会以很高的频率发生，因而不会产生任何繁重负载，但可能出现可用性方面的问题。创建新用户或更改口令可能很麻烦，并且世界另一端的主 KDC 有时会暂时不可用。

如果组织分布于不同地理位置并且其政策规定在每个站点本地处理管理任务，创建多个 Kerberos 域（为每个管理中心创建一个）可能会是比较好的做法。这样每个域都会有位于本地的自己的主 KDC。通过在域之间设置信任关系，一个域中的用户仍可访问另一个域中的资源。

要安排多个域，最轻松的方式是使用一个全局域（例如 EXAMPLE.COM）和不同的本地域（例如 ASIA.EXAMPLE.COM、EUROPE.EXAMPLE.COM）。如果全局域配置为信任每个本地域，并且每个本地域配置为信任全局域，则任何一对域之间都将具有完全可传递的信任，并且任何主体都可以与任何服务建立安全连接。如何确保对资源（例如该服务提供的文件）的适当访问权限将取决于所用的用户名查找服务，以及 NFS 文件服务器的功能，这不在本文档的范畴内。

在域加入过程中，服务器和客户端确立安全关系。在客户端上，需要执行以下任务来加入 Windows 域控制器提供的现有 LDAP 和 Kerberos SSO 环境。整个加入过程由 YaST 域成员资格模块来处理，该模块可以在安装过程中运行或在已安装系统中运行：

客户端引导过程中，将启动 winbind 守护程序并检索计算机帐户的初始 Kerberos 票据。winbindd 自动刷新计算机票据以保持其有效。为了跟踪当前的帐户策略，winbindd 定期查询域控制器。

GNOME 的登录管理器 (GDM) 已经过扩展，允许处理 Active Directory 域登录。用户可以选择登录其计算机已加入的主域或主域的域控制器已经与之确立信任关系的可信域之一。

如第 8.2 节 “有关 Linux Active Directory 支持的背景信息”中所述，用户身份验证由多个 PAM 模块调解。如果出现错误，错误代码将转换为用户易于理解的错误消息，这些消息是 PAM 通过任意支持的方法（GDM、控制台和 SSH）在登录时提供的：

在成功的身份验证期间，客户端从 Active Directory 的 Kerberos 服务器中获得票据授权票据 (TGT) 并将其储存在用户的身份凭证缓存中。它还可以在后台续订 TGT，而无需用户的交互。

SUSE Linux Enterprise Server 对 Active Directory 用户提供本地主目录支持。如果按第 8.3 节 “为 Active Directory 配置 Linux 客户端”中所述通过 YaST 进行了配置，当 Windows/Active Directory 用户首次登录到 Linux 客户端时，系统会创建用户主目录。这些主目录的外观与标准的 Linux 用户主目录相同，可独立于 Active Directory 域控制器工作。

使用本地用户主目录可以访问此计算机上的用户数据（即使 Active Directory 服务器断开连接），前提是 Linux 客户端已配置为执行脱机身份验证。

公司环境中的用户必须能够成为漫游用户（例如，切换网络，甚至在断开连接的情况下工作一段时间）。为使用户能够登录断开连接的计算机，已经将大量的缓存集成到 winbind 守护程序。winbind 守护程序即使在脱机状态下都可强制实施口令策略。它跟踪失败的登录尝试次数并根据 Active Directory 中配置的策略做出反应。脱机支持默认处于禁用状态，必须在 YaST 域成员资格模块中显式启用。

当域控制器变成不可用状态时，用户仍可使用断开连接之前获得的有效 Kerberos 票据访问网络资源（不包括 Active Directory 服务器本身），这与在 Windows 中一样。域控制器联机时才能处理口令更改。与 Active Directory 服务器断开连接时，用户无法访问储存在此服务器上的任何数据。当工作站与网络完全断开连接并于稍后再次连接到公司网络时，SUSE Linux Enterprise Server 会在用户锁定再解锁桌面（例如使用桌面屏幕保护程序）时获得新的 Kerberos 票据。

YaST 包含多个可连接 Active Directory 的模块：

YaST 模块用户登录管理支持在 Active Directory 上进行身份验证。此外，它还支持以下相关身份验证和标识提供程序：

要使用 SSSD 以及 YaST 的用户登录管理模块加入 Active Directory 域，请执行以下操作：

要使用 winbind 以及 YaST 的 Windows 域成员资格模块加入 Active Directory 域，请执行以下操作：

加入 Active Directory 域之后，使用桌面上的显示管理器或控制台从工作站登录到该域。

重要：域名

如果域名以 .local 结尾，可能无法成功加入域。以 .local 结尾的名称可能导致与多路广播 DNS (MDNS) 相冲突，在 MDNS 中，.local 是为链路本地主机名保留的。

注意：只有管理员能够注册计算机

只有域管理员帐户（例如 Administrator）能够将 SUSE Linux Enterprise Server 加入 Active Directory。

要检查您是否已成功在 Active Directory 域中注册，请使用以下命令：

要对 Active Directory 服务器进行 GNOME 客户端计算机身份验证，请执行以下操作：

如果已进行相应的配置，SUSE Linux Enterprise Server 会在已经过身份验证的每个用户通过 Active Directory 首次登录时，在本地计算机上创建一个用户主目录。这样，您便可以获享 SUSE Linux Enterprise Server 的 Active Directory 支持，同时确保您的 Linux 计算机完全正常运行且任您操控。

除了使用图形前端登录到 Active Directory 客户端计算机以外，您还可以使用基于文本的控制台登录，甚至是使用 SSH 远程登录。

要从控制台登录到 Active Directory 客户端，请在 login: 提示符处输入 DOMAIN_NAME\USER_NAME，并提供口令。

要使用 SSH 远程登录到 Active Directory 客户端计算机，请执行以下操作：

scrub 利用重复模式来重写硬盘、文件和其他设备，旨在让从这些设备恢复数据变得更困难。它有三种基本操作模式：针对字符或块设备、针对文件，或者针对指定目录。有关详细信息，请参见 man 1 scrub 手册页。