Windows域环境中TGT有效期由Active Directory域策略强制决定，关键参数是“Maximum lifetime for user ticket”，对应DC注册表项MaxTicketAge，修改后需gpupdate /force且仅对下次登录生效。
tgt有效期不是客户端能随便改的，必须由域控制器（dc）统一控制；直接改本地配置或krb5.conf基本无效。
Windows域环境中TGT有效期由谁决定
Active Directory域策略强制下发，客户端无权覆盖。关键参数是“Maximum lifetime for user ticket”，对应注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\Parameters\MaxTicketAge，单位为小时。
- 该值修改后需在DC上执行
gpupdate /force，且仅对用户下次登录生效 - 常见取值：生产环境多为8小时（微软默认），高安全场景设为2–4小时，PAW环境可能低至30分钟
- Linux客户端（如RHEL/CentOS）即使配置了
ticket_lifetime在/etc/krb5.conf中，也会被DC返回的票据实际值覆盖
renew_till才是续期天花板，不是ticket_lifetime
很多人以为TGT过期前都能无限续，其实受renew_till硬性限制——它通常设为ticket_lifetime的2–3倍，但不能超过域策略中“Maximum lifetime for user ticket renewal”的上限值。
- 例如：TGT设为8小时，
renew_till配24小时，但若域策略中该上限只设了12小时，则第12小时一到就无法续，哪怕TGT本身还没过期 - 用户看到的错误通常是
KDC_ERR_RENEW_NEEDED或kinit: KDC can't fulfill requested option while renewing credentials - 检查当前票据的
renew_till时间，可用klist -v（Linux/macOS）或klist（Windows）查看详细字段
调整后为什么用户没立刻感知变化
策略变更不触发已登录用户的票据刷新，TGT生命周期在获取那一刻就已固化，直到过期或显式销毁。
- 已登录用户必须重新登录（或运行
kdestroy+kinit）才能拿到新策略下的TGT - 服务端（如Apache、SSH）若缓存了旧TGT验证上下文，可能继续接受已过期但尚未被KDC吊销的票据——这不是策略失效，而是服务未主动校验
renew_till或未启用krb5_get_renewed_creds - 某些应用（如Java的JAAS）会忽略
renew_till，只依赖ticket_lifetime，导致续期失败却无明确报错
真正难控的不是设置值，而是renew_till与客户端行为的耦合——它决定了“还能续多久”，而很多工具默认不主动续，或续时没带RENEW标志位，结果TGT一过期就断连，用户根本不知道中间还有个可续窗口。
