Java Kerberos认证异常：客户端用户被识别为服务账户问题排查

核心问题分析 #

出现该问题的核心原因是服务端错误地使用自身服务账户的凭证完成认证流程，而非正确解析并验证客户端携带的用户令牌，导致身份识别混淆。

具体排查点与修复方案 #

1. 检查JAAS配置文件（jaas.conf） #

确保JAAS配置为服务端接受认证的模式，而非客户端发起模式。正确的配置示例如下：

com.sun.security.jgss.krb5.accept {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    keyTab="C:/path/to/your/rikim.keytab"
    principal="HTTP/serverA.yourdomain.com@YOURDOMAIN.COM"
    storeKey=true
    isInitiator=false;
};

• 关键配置：isInitiator=false明确这是服务端接受认证的配置；storeKey=true确保加载服务账户的密钥表凭证；principal必须是AD中注册的服务主体名称（SPN），而非服务账户的用户主体。

2. 调整GSSContext双向认证参数 #

代码中requestMutualAuth(false)关闭了双向认证，这会导致服务端无法正确获取客户端身份。需开启双向认证：

gssContext.requestMutualAuth(true); // 修改为true，强制双向身份验证

双向认证要求客户端验证服务端身份，同时服务端能准确解析客户端的用户令牌信息，避免身份混淆。

3. 验证服务主体名称（SPN） #

确认kerberosConfig.getServiceprincipal()返回的是正确的服务主体，格式应为HTTP/serverA.yourdomain.com@YOURDOMAIN.COM，必须与AD中为服务账户rikim注册的SPN完全一致。如果SPN不匹配，服务端无法正确匹配客户端令牌，会 fallback 使用自身服务账户身份。

4. 检查令牌处理逻辑 #

添加日志确认令牌解码是否正确，避免因Base64处理错误导致令牌损坏：

System.out.println("原始令牌长度：" + kerberosToken.length());
byte[] tokenBytes = Base64.getDecoder().decode(kerberosToken);
System.out.println("解码后令牌长度：" + tokenBytes.length);

如果解码后的令牌长度异常，说明客户端发送的令牌在传输或处理过程中被篡改，需修正编码/解码逻辑。

5. 分析Kerberos调试日志 #

利用开启的sun.security.krb5.debug=true，重点查看以下日志内容：

• 服务端加载的服务主体和密钥表信息
• 客户端令牌中的用户主体名称
• GSSContext初始化过程中的身份验证步骤
  如果日志中出现Using subject相关内容，说明服务端错误使用了自身的Subject，而非客户端的身份信息。

修复后的关键代码示例 #

public LoginResponse authenticateWithKerberos(String kerberosToken) throws GSSException {

    System.setProperty("java.security.krb5.conf", "C:/Windows/krb5.conf");
    System.setProperty("java.security.auth.login.config", "C:/Windows/jaas.conf");
    System.setProperty("sun.security.krb5.debug", "true");
    System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
    System.setProperty("sun.security.krb5.disableReferrals", "true");

    // 令牌Base64解码处理
    kerberosToken = kerberosToken.replace('-', '+').replace('_', '/');
    int paddingLength = 4 - (kerberosToken.length() % 4);
    if (paddingLength < 4) {
        kerberosToken += "=".repeat(paddingLength);
    }

    byte[] tokenBytes = Base64.getDecoder().decode(kerberosToken);
    GSSManager gssManager = GSSManager.getInstance();
    Oid kerberosOid = new Oid(kerberosConfig.getOid());
    GSSName targetName = gssManager.createName(kerberosConfig.getServiceprincipal(), GSSName.NT_HOSTBASED_SERVICE);
    GSSContext gssContext = gssManager.createContext(targetName, kerberosOid, null, GSSContext.DEFAULT_LIFETIME);
    
    // 开启双向认证
    gssContext.requestMutualAuth(true);
    gssContext.requestCredDeleg(true);

    try {
        // 处理initSecContext返回的响应（Negotiate流程中服务端可能无需返回，但需规范处理）
        byte[] response = gssContext.initSecContext(tokenBytes, 0, tokenBytes.length);
        if (response != null && response.length > 0) {
            System.out.println("生成响应令牌长度：" + response.length);
        }
        
        int atIndex = gssContext.getSrcName().toString().indexOf('@');
        String username = gssContext.getSrcName().toString().substring(0, atIndex);
        DetailUserResponse detailUserResponse = getUserWithSystemDetail(username);
        String token = jwtUtil.generateToken(detailUserResponse.getUser(), detailUserResponse.getSystemDetail());

        return new LoginResponse(token, detailUserResponse.getUser());
    }catch (Exception e){
        throw new UserNotFoundException(MessageConstants.USER_NOT_FOUND);
    }finally{
        if (gssContext != null) {
            gssContext.dispose();
        }
    }
}

额外验证步骤 #

1. 使用kinit ariandop命令模拟用户获取令牌，再发送请求到端点，观察调试日志中的身份信息。
2. 用setspn -L rikim命令确认AD中服务账户已注册正确的SPN。
3. 检查密钥表文件（keytab）的权限，确保服务进程能读取该文件。

内容的提问来源于stack exchange，提问作者Riki Ahmad