调整Jenkins登出超时时间无效，切换AD后用户仍被提前登出

嘿，我之前也碰到过一模一样的情况——明明通过脚本确认Jenkins的全局会话超时是14400分钟，但AD用户一登录，大概1.5小时就被自动登出，其他集成AD的服务却完全正常。这问题十有八九是Active Directory插件自带的会话设置覆盖了Jenkins全局配置，给你整理了一套排查和解决步骤：

第一步：检查AD插件的独立会话配置 #

Jenkins的AD插件有时候会有自己的超时设置，完全不遵循全局的maxInactiveInterval，你可以这么操作：

• 依次进入「Manage Jenkins」→「Configure Global Security」
• 找到「Security Realm」下的「Active Directory」，点击「Advanced」展开高级选项
• 查看是否有「Session Timeout」相关设置：
  • 如果存在，要么将其值改为你期望的14400分钟，要么选择「Use Jenkins global session timeout」让它继承全局配置
  • 设置完成后记得保存，最好重启Jenkins生效

第二步：用脚本强制AD插件继承全局设置 #

如果你的AD插件版本没有图形化的超时配置选项，就在Jenkins脚本控制台执行这段代码：

import jenkins.model.Jenkins
import hudson.plugins.active_directory.ActiveDirectorySecurityRealm

def realm = Jenkins.instance.getSecurityRealm()
if (realm instanceof ActiveDirectorySecurityRealm) {
    realm.setSessionTimeout(null) // 设置为null表示继承全局会话超时
    Jenkins.instance.save()
    println "已配置AD插件继承全局会话超时设置"
} else {
    println "当前Jenkins安全域并非Active Directory"
}

执行完成后重启Jenkins，再用AD用户登录测试。

第三步：排除域策略的小概率影响 #

虽然你提到其他AD服务没有问题，但还是可以快速确认：是否存在针对Jenkins服务器或特定用户组的域会话超时策略？比如部分域会设置「交互式登录会话超时」，如果Jenkins的AD认证走的是该流程，可能会受此影响。不过这个概率较低，仅在前面步骤无效时再排查。

最后验证效果 #

重新用AD用户登录后，再次执行你之前的验证脚本确认配置：

import org.kohsuke.stapler.Stapler; Stapler.getCurrentRequest().getSession().getMaxInactiveInterval() / 60

如果返回结果仍为14400，就观察1.5小时后是否还会被自动登出。若问题依旧，可前往「Manage Jenkins」→「System Log」搜索「session」或「timeout」相关日志，大概率能找到AD插件覆盖会话设置的提示信息。

内容的提问来源于stack exchange，提问作者Justin Smith