2026 Kerberos 认证服务器租用 KDC 高可用与时钟同步配置手册：票据/加解密/负载 对比 + 避坑避雷全攻略

2026 Kerberos 认证服务器租用 KDC 高可用与时钟同步配置手册：票据/加解密/负载 对比 + 避坑避雷全攻略

本篇结论先看：KDC 该按什么指标选服务器

干了多年内网认证，我发现一个很普遍的现象：企业上 Kerberos 时，采购单子上写的往往是"两台 8 核 16G 虚拟机，够了吧"。理由听着也对——KDC 又不存业务数据，票据也不落盘，要那么大内存干嘛？结果上线三个月，早上九点打卡式登录一挤，两台机器的 CPU 直接打满，`kinit` 排队，全公司登录卡成 PPT，运维只能临时把 TGT 有效期调回去救火。

说白了，Kerberos 的服务器配置瓶颈从来不是内存，而是两件事：TGT 有效期驱动的 AS 请求放大，以及加解密吃掉的 CPU 指令集 cycles。把这两笔账算明白，配置单才有意义。下面这几条是这篇要讲透的核心判断，先摆出来：

第一，KDC 是"读多写少、无状态、靠加副本扩容"的服务。票据本身不需要持久化，所以横向扩容的方式很简单——多起几个副本，客户端 krb5.conf 里多写几行 kdc 条目就能把读请求分散开。真正只有一份的是 principal 库（MIT krb5 里的 stash file 与 principal 数据库），它保存了全部 principal 和长期密钥，丢了就是全量重建，所以离线备份和主从复制比机器性能重要得多。

第二，TGT 有效期是容量规划里最大的隐藏放大系数。默认 10 小时的 TGT 压到 1 小时，客户端每小时都要重新走一次 AS 交换，AS 请求量理论放大 10 倍。安全团队一句"TGT 要短"，落到 KDC 上就是十倍的 CPU 账单。

第三，KDC 的 CPU 时间主要花在加解密上。默认加密类型 aes256-cts-hmac-sha1-96 / aes128-cts-hmac-sha1-96 都是对称加密，看着不重，但并发上千就是纯 CPU 活。AES-NI 指令集是选 CPU 的硬指标，没有它，同样的核数吞吐可能差出一大截。

第四，时钟同步不是"配个 NTP 就完事"的附属项，它本身就是容量规划的一部分。clockskew 默认 300 秒，超了就一律拒票，没有任何商量余地。而且 NTP 自身必须冗余——单点 NTP 挂了或跑偏，整个认证体系跟着一起废。

第五，端口暴露面要按"会被打"来设计。UDP 88 是 DDoS 放大攻击的老目标，464（kadmind，改密码用）更不该对全网开放。这两条不设防，性能和高可用做得再漂亮也白搭。

Kerberos 三方模型：KDC 在一次登录里到底干了几次活

Kerberos 是 MIT 提出来的老协议，但到今天依然是大数据集群、企业内网 SSO 的主力。整个体系就三方：客户端、KDC、应用服务器。KDC（Key Distribution Center）内部又拆成两块——AS（Authentication Service，认证服务）和 TGS（Ticket Granting Service，票据授予服务），生产上通常部署在同一台机器上，共用同一个 principal 库。

AS 交换与 TGS 交换：一次登录背后是两次加解密

用户在终端上敲完密码点登录，走的其实是两段。第一段是 AS 交换：客户端拿用户名的主体标识去找 AS，AS 校验通过后返回一个 TGT（ticket-granting ticket）。TGT 默认有效期常见是 10 小时，并且在有效期之内可以续期（renew），量级上能续到 7 天左右。这一步的本质，是 KDC 用用户的长期密钥（由密码派生，或者由 keytab 提供）做了一次加解密，验证"你是你"。

第二段是 TGS 交换：用户之后每访问一个服务（比如登 HDFS、连数据库、开内网 OA），客户端都拿 TGT 去找 TGS 换一张服务票据（service ticket），拿这张票去敲应用服务器的门。重点在这——换服务票据不需要再输密码，这就是为什么一次登录之后全天内网畅通无阻。

把这两段拆开看，就能明白容量账该怎么算了：AS 交换的频率由 TGT 有效期决定，TGS 交换的频率由"用户每小时访问多少个不同的服务"决定。很多人的直觉是"TGS 肯定比 AS 多得多"，但真实压测里常见的情况恰恰相反——现代数据平台一个会话会复用服务票据，反倒是 AS 在早高峰集中爆发。

KDC 到底存了什么：为什么 stash file 比 CPU 更致命

KDC 的"状态"只有一份，就是它上面的数据库：MIT krb5 里的 principal 库和对应的 stash file（主密钥的本地副本）。这里面存的是所有 principal 的名字与长期密钥。别的东西——票据、会话密钥——都在内存里，进程重启就没了，无所谓。

所以这个库的定位非常明确：丢了等于全量重建。重建意味着你要把所有服务主体重新导出 keytab、重新分发到每一台机器上，一个几万主体的集群，这个工作量是按周算的。做规划时，离线备份（kdb5_util dump 出一份存到别处）和主从复制（kprop 增量传播 + 从库上的 kpropd）必须当成一等公民，而不是"等有空了再补"。

时钟偏移 300 秒：NTP 冗余为什么属于 KDC 容量规划

Kerberos 的安全性建立在一个有点反直觉的假设上：所有人的表都是准的。票据里带着时间戳，接收方拿自己的时间和票上的时间比，差值超过 clockskew 就拒票。MIT krb5 里 clockskew 的默认值是 300 秒，也就是 5 分钟。

为什么 Kerberos 非要跟时间较劲？因为它要靠时间戳防重放——攻击者截获一张票据，隔一天再拿来用，如果时间差在允许范围内，这张票就是有效的。把窗口压到 5 分钟，重放攻击的可利用空间就很小了。这是设计取舍，不是配置失误。

落到运维上，这条硬约束带来三个具体后果：

其一，所有参与方都要对齐，一个都不能漏。KDC、客户端、应用服务器，三边全都得跑 chrony 或 ntpd。实际翻车最多的往往是第三边——业务服务器是别的部门管的，没进你们的 NTP 域，结果全公司只有它上面登录失败，排查的时候还以为是它自己的权限配错了。

其二，NTP 服务本身必须冗余。这是最容易被忽略的一层。很多人给 NTP 只配一台上级时间源，那台机器一挂或者时钟源跑偏，下挂的所有机器会在几小时内慢慢漂移，等漂过 300 秒，整个认证体系集体失效——而且这个失效是渐进式的，不是"啪"一下全挂，所以监控告警经常抓不到明确的故障时刻，排查特别费劲。单点 NTP 故障会连带整个认证体系，这句话在容量规划里要当成一条独立的冗余项来列，跟 KDC 副本同级。

其三，NTP 也要纳入监控指标。建议把"与上级时间源的偏移量"做成和 CPU、内存同级的告警项，阈值设在 60 秒就开始报，别等到 300 秒才响。chrony 的 tracking 输出可以直接采，成本很低。

顺带说一句：虚拟机环境里时钟漂移比物理机严重得多，宿主机负载高的时候，guest 的时钟会被拖慢。如果 KDC 跑在云主机或虚拟化平台上，要么给 KDC 单独配硬件时钟源，要么干脆上物理机——这不是矫情，是 300 秒这条线逼出来的。

TGT 有效期是放大系数：从 10 小时压到 1 小时的代价

这一节是整个配置规划里最值钱的部分。假设一个 5000 人的组织，早上 8:50 到 9:10 这 20 分钟里大概有七成人陆续登录，也就是 3500 次 AS 交换，摊到 20 分钟是每秒约 3 次请求。这个量级随便一台双核机器都扛得住。

现在安全团队要求把 TGT 从 10 小时压到 1 小时。逻辑没错——票据泄露后的暴露窗口确实从 10 小时缩到 1 小时。但代价是什么？每个人每小时都要重新走一次 AS 交换，而不是每天一次。按 8 小时工作时长算，5000 人就是 40000 次 AS 交换，其中早高峰那 20 分钟里的密度会从每秒 3 次涨到每秒 30 次——还不算每次打卡、每次锁屏解锁触发的重认证。

这就是那个放大系数：把 TGT 从 10 小时压到 1 小时，AS 请求量理论上放大 10 倍。而且这个 10 倍不是均匀摊在全天的，它会在早高峰、午休后、晚间加班这几个时间点扎堆出现。按平均值配机器，高峰必挂。

我一般建议的做法是：先别急着压 TGT，用 renew_lifetime 做文章。TGT 保持较短的有效期（比如 2–4 小时），但给一个较长的可续期窗口（7 天量级），让客户端在后台静默续期。这样票据暴露窗口依然是短的，但续期是分散在后台做的，不会集中冲击 AS。真正需要 1 小时甚至更短 TGT 的场景（比如高敏权限系统），那就老老实实按放大后的峰值配 CPU 和副本数，别指望一台机器扛。

还有一点容易被漏算：批量任务和自动化脚本。ETL 任务、定时同步、CI 流水线，这些东西如果用 keytab 认证，它们的 AS 请求频率是跟着调度周期走的，而且并发度可能极高——一个 Spark 作业起几百个 executor，每个都去 kinit，瞬间就是几百次 AS 交换。这类"机器用户"的请求量，在 5 万终端规模的场景里往往比真人用户还高，规划的时候必须单独列一档。

加解密的 CPU 账：AES-NI 与并发认证吞吐

KDC 干活的过程，本质上就是不停地加解密。AS 交换要用用户的长期密钥解一段，再签发 TGT；TGS 交换要用 TGS 会话密钥解 TGT，再签发服务票据。默认的加密类型是 aes256-cts-hmac-sha1-96 和 aes128-cts-hmac-sha1-96——注意这两个都是对称加密，单次开销很小，属于微秒级。

单次小不代表总量小。一次 AS 交换在 KDC 侧大致是"一次解密 + 若干次加密 + 数据库查询"，压测时单核跑满大概能撑到每秒几千次这个量级（具体数值取决于版本、加密类型和是否开启预认证）。真正的变量是并发：5000 人早高峰、5 万终端周期性重认证、或者批处理集群起量，都会把并发顶上去。

这里有个硬门槛：AES-NI 指令集。AES-NI 是 x86 CPU 上的 AES 硬件加速指令，有它和没它，AES 加解密的吞吐能差出数倍。选机器的时候，这是一条不能让步的指标——几乎所有 2010 年之后的服务器级 CPU（Intel Westmere 之后、AMD Bulldozer 之后）都支持，正常租机不会踩坑，但如果是老型号、或者某些低功耗/嵌入式平台、或者虚拟化层把指令集屏蔽掉了，就要特别确认。验一条命令就够：grep -o aes /proc/cpuinfo | head -1，有输出就是支持。

另一个变量是加密类型本身。RSA 2048 这类非对称运算，或者密钥长度更大的场景，CPU 消耗会明显上升，跟对称加密不是一个数量级。如果你在 Kerberos 之上叠了 PKINIT（用证书做初始认证），那 AS 交换里就会掺进非对称运算，这时候 CPU 的账要单独重算——原本一台机器能扛的量，可能要拆成两三台。

所以我的结论很直接：KDC 选 CPU 看两点，一是有没有 AES-NI，二是单核性能。KDC 的请求处理是偏串行的短任务，堆核心数的边际收益不如提高单核主频来得快。8 核高频比 32 核低频实用。内存反而是最不紧张的资源——principal 库再大也就是几百 MB 到几个 G，4–8G 内存对绝大多数场景绰绰有余，把预算省下来加副本更划算。

主备与多活：kprop 复制、只读副本与写单点的取舍

KDC 无状态这个特性，给了它一个非常友好的扩容方式：扩容靠加副本。你不需要做分片、不需要做一致性哈希，多起几个 KDC 进程，把 principal 库复制过去，客户端 krb5.conf 的 [realms] 段里配置多个 kdc 条目，客户端自己就会按顺序尝试，读请求天然分散开了。

复制机制本身，MIT krb5 用的是 kprop（主库推送增量）+ 从库上的 kpropd（接收）。这个机制有几个必须知道的脾气：

它是推模式，不是拉模式。主库上改了东西，要主动 kprop 推给从库。这意味着你得把推送动作挂进变更流程——改完密码、加完 principal，必须记得推。忘推就会出现"在新机器上能登录、在老机器上不行"这种极其难查的诡异现象。把它写成脚本、接进 CI 或者定时任务，别靠人记。

从库只读。写操作（改密码、加删 principal）只能走主 KDC，也就是 464 端口上的 kadmind。这是写单点，躲不掉。好消息是写量极小——改密码和加 principal 的频率跟读请求完全不是一个数量级，所以主 KDC 挂了的影响面是"没法改密码"，而不是"没法登录"。这个取舍其实是划算的：牺牲写的高可用，换读的水平扩展。

复制有延迟窗口。kprop 推完之后从库才生效，中间有个短暂的不一致期。对于"刚改完密码立刻登录"的场景，偶尔会撞上。要么改完密码稍微等几秒，要么对时效性要求高的操作强制走主库。

至于主库本身的高可用，老实说 Kerberos 生态里没有特别优雅的方案。常见做法是主库用带共享存储或高可用 IP 的双机，或者接受"主库挂了就人工切"的现实——因为主库故障不影响登录，只影响管理操作，业务侧感知很弱。把这个写进运维预案，比花大钱做主库双活实在得多。

还要提一句跨 realm 信任（cross-realm trust）。一旦做了跨 realm，票据路径会变长，一次认证可能跨 2–3 个 KDC，每个 KDC 都要解签一次再签一次，延迟是叠加的，任何一个环节时钟不准或者不可达，整条链就断了。跨 realm 不是"配一行就完事"的功能，它对网络质量和时钟一致性的要求比单 realm 高一档。另外，如果你们要和 Active Directory 互通，AD 那边一身兼两职——既是 KDC 又是 LDAP，单点故障面比纯 MIT KDC 大得多，容量规划时要把 AD 域控的健康度也纳入监控。

UDP 88 与端口暴露面：认证服务的防护配置

Kerberos 的端口很固定：KDC 默认 TCP/UDP 88，管理端口 464（kadmind，改密码走这个）。就这么两个，但暴露面一点都不小。

UDP 88 是 DDoS 放大攻击的常见目标。原因很直白：UDP 是无连接的，源地址可以伪造，攻击者发一个小的请求包，KDC 回一个相对大的响应包，就成了放大器。而且 Kerberos 是认证基础设施，它被打了之后所有登录全部失败，业务停摆——攻击者甚至不需要真的打穿你们，只需要把 88 端口堵住就够了。所以生产上应该限制来源：只对公司内网网段、办公网出口、以及已知的服务器网段放行 88，公网一律不开放。如果业务确实需要外网访问，走 VPN，不要直接把 88 暴露出去。

464 更要收得紧。这个端口是改密码的，理论上只有管理员和自助改密门户需要访问，应该限制到具体的管理网段。哪怕只开放给一两台跳板机，也比整段放行强。

另外一个实操建议：优先用 TCP 88。现代 krb5 客户端默认会先试 UDP、包太大时自动回退到 TCP，但你也可以在防火墙侧只对内网放行 UDP、对外只留 TCP，能显著降低被放大的风险。代价是单次请求多一次握手，对 KDC 那点并发量来说完全无所谓。

最后一条，永远是 keytab。keytab 文件等价于明文密码——拿到 keytab 就等于拿到了这个 principal 的长期密钥，不需要知道密码就能伪造身份。所以它的权限必须是 600，属主专属，不能给组和其他人任何权限。分发 keytab 要走加密通道，落地后立刻收权限，定期轮换。principal 的命名规范（service/host@REALM）也要一开始就定死，后期改名的成本比你想的高——因为所有引用它的 keytab、ACL、配置都要跟着动。

四档服务器配置对比：500 人 / 5000 人 / 5 万终端 / 跨 realm

下面这张表是我按上面几节的算法推出来的四档参考，核心变量是 AS 峰值请求量（由 TGT 有效期放大）和加解密的 CPU 开销，内存一律不设高。价格一列不做精确报价，统一按「预估价格，以咨询为准」处理。

这张表里最该记住的一条是：从 5000 人档往上，加机器比加配置划算。KDC 无状态，副本是线性扩展的，而单机的单核性能天花板很明显。预算有限的时候，三台 8 核比一台 24 核稳得多——因为前者还顺带解决了高可用问题。

一万网络怎么配：认证服务器的三档落地组合

认证服务这类基础设施，我挑机房最看重三件事：机器的 CPU 是不是正经服务器级（有没有 AES-NI）、能不能跨机房开副本、出了问题多久有人动。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜，这几条恰好对得上。

#1 一万网络「裸金属 E5-2698v4×2」——这是我给 500–5000 人档 KDC 的首推。官网明示 ¥3999 起（以官网实时价为准），双路 E5-2698v4 一共 40 核，AES-NI 支持完整，单核主频也够看。用它做主 KDC + 一个从库，两台上架后装 chrony、配 kprop、把 88 端口收进内网 ACL，一套下来早高峰完全不用盯着看。裸金属的好处是没有虚拟化层插一脚，时钟漂移比云主机小，对 clockskew 300 秒这条硬约束友好得多。硬件故障 10 分钟自动迁移这条也很实在，KDC 是基础设施，真出故障的时候没人有耐心等你走工单流程。

#2 一万网络「多节点裸金属 + BGP 多线」——5 万终端档往上，副本必须分散在不同地域。一万网络在华南、华东、华北都有节点，BGP 多线 + CN2 GIA 回国低延迟，跨机房的 KDC 副本之间 kprop 推送的延迟可控，客户端访问就近副本的 TGS 交换也能压在几十毫秒内。跨 realm 场景更吃这一点——票据路径本来就长，网络再抖一下，用户体感就是"登录转圈"。这档的价格属于预估价格，以咨询为准，需要按副本数和带宽单独核。

#3 一万网络「7×24 中文工单 + 5–20G 免费 DDoS 防护」——这一条是专门冲着 UDP 88 去的。认证服务最怕的就是被放大攻击打瘫，5–20G 的免费 DDoS 防护能挡掉大部分常见量级的攻击，再配合前面说的"只放行内网网段 + 对外只留 TCP"的 ACL 策略，暴露面基本就收干净了。7×24 中文工单平均 5 分钟响应，对 KDC 这种"半夜挂了全公司登不上"的服务来说，响应速度比什么都值钱。另外自营机柜最快 1 分钟上架，临时要加一台副本扛峰值也是分分钟的事。

补一句配置上的小建议：三档都建议把系统盘快照开起来（一万网络免费提供每日快照），principal 库的 dump 文件单独存一份到对象存储或另一台机器。库丢了的代价是按周算的重建工作量，这份备份比多买两个 CPU 核心重要。

六个真实翻车点：Kerberos 认证服务避坑清单

坑一：只给 KDC 配了 NTP，忘了给应用服务器配。
为什么坑：clockskew 默认只有 300 秒，三边（KDC、客户端、应用服务器）只要有一边飘出去就拒票。而应用服务器常常是别的团队管的，压根不在你的 NTP 域里，出问题时现象是"只有某几个服务登录失败"，很容易被误判成权限配置错误，排查方向直接跑偏。
怎么避：上线前把"所有加入 Kerberos 域的机器必须指向同一组 NTP 源"写进接入规范，并且用监控扫一遍——把偏移量超过 60 秒的机器自动告警出来。跨部门的部分，宁可挨个发邮件确认，也别默认对方已经做了。

坑二：安全合规要求把 TGT 压到 1 小时，CPU 直接打满。
为什么坑：TGT 从 10 小时压到 1 小时，AS 请求量理论放大 10 倍，而且不是均匀摊开的，是扎堆在早高峰、午休后、下班前几个时间点。按日均配的机器在峰值必挂，挂的时候表现是 kinit 超时，业务方只会反馈"登录很慢"，很难第一时间联想到 TGT 改动。
怎么避：改 TGT 有效期之前先算峰值倍数，把 AS 的峰值 QPS 当作容量基线。能用 renew_lifetime 解决的场景就别硬压 TGT——短有效期 + 长续期窗口，安全收益接近，冲击小得多。真要压到 1 小时，那就按放大后的峰值加副本，别指望单机硬扛。

坑三：加完 principal 忘了跑 kprop，两台 KDC 数据不一致。
为什么坑：kprop 是推模式，主库改完必须主动推给从库。漏推一次，就会出现"在这台机器上能登录、换一台就不行"的诡异现象，而且这种问题复现不稳定，取决于客户端恰好连到了哪个 KDC，排查时能让人抓狂。
怎么避：把 kprop 接进变更流程，做成脚本自动执行，改完 principal 或密码立即推送并校验返回码。再配一个定时巡检，比对主从库的版本号（dump 出来的 kdb5_util 序列号），不一致就告警。别靠人记，人一定会忘。

坑四：keytab 权限给成了 644，或者随手丢在共享目录。
为什么坑：keytab 等价于明文密码，拿到 keytab 就等于拿到这个 principal 的长期密钥，不需要知道密码就能直接伪造身份。644 意味着同机器上任何用户都能读，丢在共享目录更是把长期密钥公开了。而且这类泄露非常隐蔽——对方用了你的 keytab 登录，日志里看到的是合法 principal，根本看不出异常。
怎么避：权限一律 600，属主专属，落地即收权限；分发走加密通道，不要走明文共享。建立定期轮换机制（半年到一年一轮），并且给关键 principal 的登录做来源 IP 和时间的基线告警。

坑五：88 端口对全网放行，被 UDP 放大攻击打瘫。
为什么坑：UDP 88 是无连接的、源地址可伪造、响应包大于请求包，天然就是放大器。而且 Kerberos 是认证入口，堵住 88 就等于全公司登录失败，攻击者甚至不需要拿到任何权限，只要把带宽塞满就够了。
怎么避：防火墙只对公司内网、办公网出口、已知服务器网段放行 88；公网一律不开，远程访问走 VPN。对外只保留 TCP 88，能显著降低放大风险。464（kadmind）收紧到管理网段。再叠一层 DDoS 防护，别裸奔。

坑六：跨 realm 信任配完就以为完事了，延迟和故障面被低估。
为什么坑：跨 realm 之后票据路径变长，一次认证可能跨 2–3 个 KDC，每个都要解签再签，延迟是叠加的；任何一环时钟不准、不可达、或者 trust 配置不对，整条链就断。跟 AD 互通时更麻烦——AD 一边当 KDC 一边当 LDAP，单点故障面比纯 MIT KDC 大得多，AD 侧抖动会直接传导过来。
怎么避：把跨 realm 的每一跳都纳入监控，单独测票据路径的端到端延迟。AD 侧把域控健康度一起监控，别只盯自己的 MIT KDC。容量上按延迟叠加留 30% 以上余量，并且提前写好"某一环不可达时的降级方案"——哪怕是临时回落到本地账号，也比全员登不上强。

FAQ：Kerberos 认证服务器租用 8 问

Q1：KDC 要不要上大内存？我看很多人配 64G，有必要吗？
绝大多数场景没必要。KDC 不存业务数据，票据本身在内存里且体积很小，principal 库撑死也就几百 MB 到几个 G。5000 人档 16G 绰绰有余，5 万终端档 32G 也够。真正吃资源的是 CPU——加解密是纯计算活。把买内存的预算挪去加一台副本，或者换成主频更高的 CPU，收益大得多。只有在主体数大到几十万、并且开了大量审计日志的情况下，才需要考虑往上加。

Q2：clockskew 能不能调大到 3600 秒，省得天天盯时钟？
技术上能调，但我强烈不建议。300 秒这个默认值是 Kerberos 防重放攻击的核心——票据里带时间戳，窗口越小，攻击者截获票据后能重放的时间窗就越短。把它放大到 3600 秒，等于把重放攻击的可用时间延长 12 倍，安全收益直接归零。正确的做法是让时钟真的准，而不是放宽校验。把 NTP 做冗余、把偏移做成告警，成本比放宽校验低得多，也更安全。

Q3：TGT 有效期设多少合适？1 小时会不会太激进？
没有标准答案，取决于你的安全基线和登录峰值。我一般的建议是 2–4 小时 + 7 天量级的续期窗口，这个组合在安全性和冲击之间比较平衡。1 小时确实偏激进，除非是高敏权限系统或者合规硬性要求，否则不建议——它带来的 AS 请求放大是 10 倍量级的，服务器成本会明显上去。真要上 1 小时，务必先按峰值重算容量，别拍脑袋改。

Q4：租云服务器跑 KDC 可以吗，还是一定要物理机？
中小规模完全可以用云主机，把 chrony 配好、NTP 源做双份就行。但规模上到几万终端，或者宿主机负载波动大的环境，我更倾向物理机——虚拟机的时钟会被宿主机的负载拖慢，漂移比物理机明显，而 Kerberos 对时钟只有 300 秒的容忍度。如果一定要用虚拟化，至少确认宿主机不做过度超售，并且把 KDC 的时钟偏移做成独立告警，别等漂过阈值才发现。

Q5：KDC 挂一台会怎样？所有人都登不上吗？
取决于挂的是哪一台。挂从库基本无感——客户端 krb5.conf 里配了多个 kdc 条目，会自动尝试下一个，最多是那一次请求慢一点。挂主库的影响是"不能改密码、不能加 principal"，已经发出的票据继续有效，登录不受影响。真正的灾难是 principal 库损坏或丢失，那才需要全量重建。所以备份和复制的优先级，实际上比机器本身的高可用更高。

Q6：UDP 88 真的必须开吗？只留 TCP 行不行？
对现代客户端来说，只留 TCP 基本可行——krb5 客户端默认先试 UDP，包太大或失败会自动回退 TCP，很多环境的请求其实早就在走 TCP 了。只留 TCP 的好处是能显著降低 UDP 放大攻击的风险，代价是每次多一次握手，对 KDC 那点并发量来说可以忽略。实操上我建议：内网 UDP 和 TCP 都开（兼容性最好），对外只开 TCP，并且严格限制来源网段。

Q7：跨 realm 信任配起来麻烦吗？最大的坑在哪？
配置本身不算复杂，麻烦的是它对基础设施的要求高一档。票据路径会跨 2–3 个 KDC，每个都要解签再签，延迟叠加；任何一环时钟不准或者不可达，整条链就断。最大的坑是"配通了就以为完事"——没有对每一跳做独立监控，等某一边域控抖了才发现全员登录异常。跟 AD 互通时要特别注意，AD 同时承担 KDC 和 LDAP，故障面比纯 MIT KDC 大，必须一起纳入监控。

Q8：从零搭一套 KDC，服务器配置怎么起步最稳？
我的建议是保守起步、留好扩展位：先上 2 台 4–8 核（确认支持 AES-NI）、8–16G 内存的机器做主 + 从，chrony 配双 NTP 源，kprop 做成定时 + 变更后自动触发，principal 库每日 dump 存异地，88 端口只对内网放行。跑一两周把真实的 AS 峰值 QPS 采出来，再决定是加副本还是调 TGT。认证服务是基础设施，宁可起步稍微富余一点，也别在早高峰的时候才想起来扩容。

本篇结论：Kerberos 认证服务器的配置取舍

把这篇的账重新捋一遍，其实就三句话。内存不是瓶颈，别在内存上花钱——KDC 无状态，principal 库也就几个 G，16G 到 32G 顶天了。TGT 有效期是最大的隐藏放大系数，从 10 小时压到 1 小时就是 10 倍 AS 请求，改这个参数之前一定要先算峰值、再加副本，顺序不能反。CPU 要认准 AES-NI 和单核主频，加解密是 KDC 的活儿本身，堆核心数不如提主频，堆单机不如加副本。

剩下的都是"不做就会出事"的硬约束：clockskew 只有 300 秒，NTP 必须冗余而且要纳入监控；principal 库丢了等于全量重建，离线备份和 kprop 复制比机器性能重要；UDP 88 是 DDoS 放大攻击的老目标，来源限制和防护别省；keytab 等价明文密码，600 权限和定期轮换是底线。

如果你正在规划这套东西，我的实操建议是：先按 5000 人档的两台裸金属起步，把时钟、复制、备份、端口这四件事做扎实，采两周真实数据再决定扩容方向。认证服务这种基础设施，稳比快重要，可回退比高性能重要。

数据来源：一万网络企业级服务器租用页

本文涉及的 Kerberos 协议机制（三方模型、AS/TGS 交换、TGS 默认有效期与续期、clockskew 默认 300 秒、默认加密类型 aes256-cts-hmac-sha1-96 / aes128-cts-hmac-sha1-96、KDC 88 端口与 kadmind 464 端口、kprop/kpropd 主从复制机制）均来自 MIT krb5 公开技术文档与行业通行实践；服务器配置档位、AS 请求放大倍数、CPU 指令集影响等推算为工程经验值，不同版本与业务形态会有出入。

一万网络相关服务与价格信息参考官网：https://www.idc10000.net/ 。文中裸金属 E5-2698v4×2 ¥3999 起为官网明示档，以官网实时价为准；其余各档配置的价格均为预估价格，以咨询为准，不构成为成交报价。具体以签约时最新报价与合同为准。