Mac 上的 Kerberos SSO 与 VPN：比较两种登录路径

两种机制在 Mac 上给出同样友好的结果，底层行为却截然不同。一种通过 SSO 扩展获取 Kerberos 票据并将其交给参与的应用。另一种与身份提供商保持浏览器会话，让 Web 应用认可该会话。它们在网络需求、凭据有效期以及隧道断开那一刻会发生什么上各不相同。

两种机制，一个登录界面

票据路径依赖 Kerberos 域、密钥分发中心，以及与之同步的时钟。浏览器路径依赖可访问的身份提供商、Cookie 或令牌，以及信任该签发方的应用。两者都可以配置为在登录时启动，因此常被误认为同一项功能。由应用决定接受哪一种，而一台 Mac 完全可以同时运行两者。

比较它们，只需问：用户打开应用时，应用检查的是什么。加入 Kerberos 域的文件服务需要服务票据，再多的浏览器会话也满足不了它。现代身份提供商背后的 Web 应用需要该提供商的令牌，完全忽略 Kerberos 票据。一旦知道发生的是哪种检查，部署问题就会变得具体，而不是笼统。

Kerberos 扩展在网络上需要什么

Apple 的Kerberos SSO 扩展指南描述了原生 Active Directory 认证与主动获取票据，并与本地账户而非域绑定配合。它无法做到的是凭空造出一条通往域控制器的路径。Mac 需要一个能应答 Kerberos 服务记录的解析器，以及一条经批准隧道抵达它们的路由。干净安装的配置文件并不能证明什么，除非客户端真的能发现该域。

先检查发现，再检查凭据：Kerberos 域的 SRV 记录必须能解析，返回的地址在 VPN 启动后必须可达。时间与可达性同样重要，因为 Kerberos 会拒绝来自超出容差时钟的请求，而它产生的错误看起来像认证失败。若 Mac 在隧道断开时无法访问时间源，隧道恢复的那一刻它还会再次失败。把时钟源作为部署的一部分来修，而不是当作事件响应。

klist
sudo sntp -sS time.apple.com

按应用 VPN 决定扩展能否工作

全隧道会路由一切，从而掩盖这个问题。按应用配置只路由 VPN 配置文件中列出的应用，而 SSO 扩展本身也是一个需要网络来获取票据的进程。如果它不在映射中，本地登录成功、浏览器所需隧道也建立，票据获取却仍然失败。

阅读 VPN 配置，列出它应覆盖的每一个应用，然后通过文档化的映射机制加入 SSO 组件，而不是猜测包标识符。只映射可见客户端而忽略其背后的组件，是这类错误的经典版本。把映射与扩展放在同一个受管理配置文件中，这样一方的改动就无法悄悄让另一方失效。用一个从未在该 Mac 上登录过的用户测试，因为缓存票据可能让断掉的路径看起来正常；然后在改密之后再测一次。

浏览器身份会话是另一种契约

浏览器会话没有 Kerberos 域、没有服务票据，也没有 Kerberos 意义上的时钟容差。它有签发方、令牌有效期和刷新路径，其失效方式是永不完成的跳转，以及隐私窗口丢弃的 Cookie。只有在应用本身接受该签发方的地方，把它当作票据路径的替代品才安全。把 VPN 门户的认证响应复制到无关服务里并不是集成，无论这个捷径看起来多方便。

两种机制都部署时，要记录哪些应用用哪一种，因为支持对话取决于此。用户说已登录却打不开文件共享，描述的是两套系统，答案是票据路径从未运行。用户能打开共享却打不开内网门户，描述的是相反情况，在工单里点明机制能省掉一轮提问。

走完整序列，而不是只看零件

用一个普通已注册账户走完整条链路：本地登录、隧道、票据获取，然后对某个服务做一次真实操作。在隧道重连之后、在刻意改密之后各重复一次，因为每种情况考验的是有效期逻辑的不同部分。每个阶段单独通过，并不等于链路可用。链路才是用户的体验，也才是验收用例必须覆盖的内容。

把配置文件所有者、VPN 认证方式、域发现路径和扩展的应用映射记录在同一处。正是这份记录，让没有参与搭建的人也能复现流程。然后检查你最可能遇到的故障，即隧道断开时票据过期，并确认客户端无需重启即可恢复，因为只能在冷启动时工作的部署并不算完成。

也要记录每个阶段的所有者，因为无人维护的 Kerberos 域会变陈旧。无人能描述的链路，就是无人能调试的链路。