让 Ubuntu 通过 SSSD 接入 Active Directory：从发现域到验证登录-未完纪

原作者：Canonical / Ubuntu Server 文档贡献者；中文翻译整理：未完纪。

从基础设施前提到身份、会话与服务票据的完整流程（自绘示意图，非截图。）

把 Ubuntu 主机加入 Active Directory 后，用户可以沿用域账号登录 Linux，用户组关系也能进入本机的身份查询结果。Canonical 的这篇指南使用 SSSD 的 ad provider 完成身份与登录集成，并由 realmd 的 realm 命令负责发现域、加入域和生成配置。

本文按官方全文翻译整理，范围是把客户端接入一个已经存在且正常工作的 AD 域，不包括搭建或维护域控制器。原文末尾还涵盖 Kerberos 服务票据、Ubuntu Desktop 登录以及组策略导致的拒绝登录问题。源页面最后更新标注为 2026-07-02，但示例终端输出仍来自 2020 年的 Ubuntu 20.04；下列输出只用于解释原文，不是本次测试结果。

先确认 DNS、时间和域加入权限

SSSD 依赖域信息发现与认证链路，因此先检查基础条件，再处理登录配置。原文使用示例域 ad1.example.com，域控制器地址 10.51.0.5，客户端地址 10.51.0.11；它们只是教程环境，不能照填到真实组织。

AD 域已经配置完成，并持有允许把机器加入该域的授权凭据。
域控制器为该域提供权威 DNS，并作为客户端的主要 DNS 解析器；可用 resolvectl status 查看实际解析器。
系统时钟正确并保持同步，原文举例使用 chrony 或 ntp。
主机名、目标域、信任关系、允许登录的人群及维护回退方式已得到组织确认。最后一项是编辑补充，避免身份接入后权限范围不清。

原文指出 SSSD 管理用户认证并设置初始安全策略；Ubuntu 更完整的组策略客户端是 ADSys。启用 SSSD 不等于所有 Windows 组策略设置会自动在 Linux 生效。

安装组件，再发现域

sudo apt install sssd-ad sssd-tools realmd adcli
sudo realm -v discover ad1.example.com

这些命令会安装系统软件或访问组织网络，本文未执行。realm 来自 realmd。discover 会解析 _ldap._tcp.ad1.example.com 等记录，对域控制器执行 LDAP DSE 查询，辨识域类型并列出所需的软件。原文发现结果的关键部分为：

ad1.example.com
  type: kerberos
  realm-name: AD1.EXAMPLE.COM
  domain-name: ad1.example.com
  configured: no
  server-software: active-directory
  client-software: sssd

原输出还列出 sssd-tools、sssd、libnss-sss、libpam-sss、adcli 和 samba-common-bin 等 required-package。realmd 可借助 PackageKit 处理缺失包，指南提前安装主要组件，让后续行为更明确。DNS 能解析一个普通 A 记录并不等于 AD 的服务发现已经正常；应看 discover 的具体结果。

加入域时发生了什么

sudo realm join ad1.example.com

默认会提示输入域 Administrator 账号密码。若要使用另外一个获授权账号，添加 -U；为了减少长期使用高权限域管理员的范围，实际组织应优先采用被委派了加入权限的账号。需要详细过程时可用 sudo realm join -v ad1.example.com。这两条是同一操作的普通与详细形式，不需要连续重复加入。

原文详细日志展示了整个过程：发现域控制器，调用 adcli，确定机器的完整域名和计算机账号，使用授权用户认证，在目录中查找或创建计算机身份，设置随机机器口令，生成 host 与 RestrictedKrbHost 等主体的 keytab 条目，写入 /etc/krb5.keytab，最后启用并重启 SSSD。日志中的 “Successfully enrolled machine in realm” 表示原教程机器成功加入；本文没有得到真实环境的这一结果。

原文还提到 --one-time-password 支持以一次性口令加入域。它仍是凭据：不要把真实 OTP 写进文章、共享命令历史或日志。也不要把 /etc/krb5.keytab 当作普通配置附件传播，其中包含机器身份所需的密钥材料。

逐项看懂生成的 sssd.conf

realm 会生成 SSSD 配置、连接 PAM 与 NSS 模块，并启动服务。指南展示的 /etc/sssd/sssd.conf 如下；先检查工具的实际生成结果，不要无条件覆盖已有多个域或自定义访问策略的配置。

[sssd]
domains = ad1.example.com
config_file_version = 2
services = nss, pam

[domain/ad1.example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD1.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = ad1.example.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

权限条件不能遗漏：原文要求该文件归属 root:root、权限为 0600，否则 SSSD 会拒绝启动。确认目标是预期的配置文件后，维护者可用下面的命令修正权限；本稿没有执行。

sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 0600 /etc/sssd/sssd.conf

参数	如何理解
id_provider = ad	用 SSSD 的 AD provider 查询身份。
access_provider = ad	采用 AD 访问控制逻辑；身份能查询不代表一定获准登录。
cache_credentials = True	允许满足缓存条件的用户在 AD 不可达时离线登录。应按组织的离职撤权与设备风险要求评估。
krb5_store_password_if_offline = True	是另一个与离线 Kerberos 处理相关的选项，不能与 cache_credentials 混为同一开关；涉及凭据处理，应按组织要求评估。
fallback_homedir = /home/%u@%d	用用户名和域名组成默认家目录，例如 /home/john@ad1.example.com。
use_fully_qualified_names = True	使用 user@domain 区分身份。涉及多域或信任关系时，不宜为省输入随意关闭。
ldap_id_mapping = True	使用 AD 身份映射生成本地 ID；与已有文件所有权及跨主机 ID 策略有关。

原文特别指出，只有确信 AD 林未来不会通过信任关系引入其他域时，才应考虑取消完整域名格式。否则不同域的同名用户容易造成操作与权限判断混淆。离线缓存也意味着新改组成员关系、密码或撤销访问的效果可能不会立即体现在每台客户端上。

某些使用 socket 激活的环境可能报出 sssd-nss.socket、sssd-pam.socket 监听失败，以及 sssd-pam-priv.socket 依赖失败。源文对此给出的处理是移除 services = nss, pam。这是一项针对特定启动错误的排查步骤，不是要求所有版本都删掉该行；应结合本机软件包版本和日志判断。

补上首次登录时的家目录创建

realm 并未替教程启用 pam_mkhomedir。指南使用下面的命令，使网络用户在登录时获得对应家目录：

sudo pam-auth-update --enable mkhomedir

这是对 PAM 配置的系统修改。操作真实服务器前应保留已有管理会话或恢复入口，避免配置异常后失去管理能力。自动创建目录只处理本地目录存在性，不代表用户文件权限、配额和备份策略已经完成。

把“查得到用户”和“能完成登录”分别验证

原文用 John Smith 的域账号 john 逐步验证。先查 NSS 的 passwd 视图，再查组成员关系：

getent passwd john@ad1.example.com
groups john@ad1.example.com

官方示例分别返回下面的信息。UID、GID、组名都来自作者的环境，不是读者应当固定使用的数字。

john@ad1.example.com:*:1725801106:1725800513:John Smith:/home/john@ad1.example.com:/bin/bash
john@ad1.example.com : domain users@ad1.example.com engineering@ad1.example.com

修改域用户的组成员关系后，SSSD 缓存可能延迟反映变化。一次 getent 成功只说明身份查询可用，不能替代认证、访问策略和会话初始化验证。原文随后使用 sudo login 在登录提示中输入完整账号与密码，观察首次登录自动创建家目录。应只在获授权的测试主机上进行这样的验证。

SSH 示例把用户名和主机放在一起，出现多个 @：ssh john@ad1.example.com@10.51.0.11。为便于阅读，下面以等价的 -l 形式标明用户名，这是编辑改写：

ssh -l 'john@ad1.example.com' 10.51.0.11

原文 SSH 场景使用公钥认证，因此没有密码提示。源文还写到 SSH 密码认证默认禁用；不能把这一句推广到所有 Ubuntu 安装、云镜像和本机配置。应核对 sshd 的有效配置及组织策略，不为完成教程临时开放弱认证。SSH 登录成功也不等于已验证域密码登录成功，两种认证链路应分别理解。

检查 Kerberos 票据并访问 SMB 服务

安装 krb5-user 后，可在域用户实际登录会话中运行 klist 查看票据。原文说明 realm 也处理了 /etc/krb5.conf，因此它的示例安装过程中无需再填写额外 realm 配置。实际已有 Kerberos 配置时仍应核对合并结果。

klist

原始输出的默认主体是 john@AD1.EXAMPLE.COM，包括 krbtgt/AD1.EXAMPLE.COM@AD1.EXAMPLE.COM 票据及有效期、续期截止时间。输出中的 /tmp 缓存路径和 2020 年时间戳只是作者的示例；不要把它们当作你机器上的实际缓存位置。

原文随后以 smbclient -k -L server1.ad1.example.com 使用 Kerberos 列出域控制器共享，并再次执行 klist，观察多出 cifs/server1.ad1.example.com@AD1.EXAMPLE.COM 服务票据。为配合当前 Samba 手册，以下是明确标注的命令改写，使用 --use-kerberos=required 表达必须使用 Kerberos；执行前仍需检查安装版本支持的选项。

smbclient --use-kerberos=required -L server1.ad1.example.com
klist

Samba 当前 smbclient 手册明确列出该选项，并说明 Kerberos 连接应使用 DNS 名称而非 IP 地址。原文输出中的 ADMIN$、C$、IPC$、NETLOGON、SYSVOL 是示例共享列表，不代表当前用户具有任意共享的访问权限。列表中的“SMB1 disabled”也不构成需要开启 SMB1 的理由。

桌面登录与组策略拒绝

Ubuntu Desktop 的登录界面最初只列出本地用户，这是原文预期。首次使用域账号时，选择“Not listed?”，输入完整域用户名与密码；完成一次登录后，该用户可能出现在后续的用户列表中。本文配图采用流程示意，没有伪造桌面界面截图。

加入 AD 域之后，SSSD 默认可能应用访问相关组策略。原文记录了某项策略缺失导致登录被拒绝的情况，并链接 Launchpad #1934997 第 5 条评论。该问题状态与适用发行版需要按实际版本核对；本稿不宣称它今天仍未修复，也没有把关闭组策略校验作为通用修复。遇到拒绝登录时，应区分 DNS、时钟、凭据、缓存、PAM、SSSD 访问控制和 GPO，而不是直接绕过策略。