keytab与service principal使用及Kerberos对接AD配置问题咨询

基础认知澄清 #

• keytab的本质是Kerberos principal与对应加密密码哈希的组合文件，用于服务/主机无需手动输入密码即可完成Kerberos身份认证，你的基础认知没有问题
• Active Directory中的服务主体名称（SPN）一定会绑定到某一个AD实体上，要么是AD用户账号（服务账号），要么是AD计算机账号，SPN对应的密码就是该绑定实体的密码，不存在“服务/主机没有实际密码”的情况
• ktutil命令生成keytab时密码校验失败，核心原因通常是SPN绑定的实体与你输入密码的账号不匹配、密码错误、或加密类型与AD域配置不匹配

Kafka对接AD Kerberos场景的具体解决步骤 #

步骤1：确认SPN绑定关系 #

执行以下命令查询你创建的SPN对应的绑定账号：

setspn -L <你的SPN完整名称，示例：kafka/broker01.test.com@TEST.COM>

输出结果中会明确显示该SPN绑定的AD账号，后续生成keytab时需要使用该账号的密码。

步骤2：生成keytab（两种方案，优先选择方案1） #

• 方案1：AD域控制器端生成（错误率最低）
  用域管理员权限在AD域控制器打开命令提示符，执行以下命令：

  ktpass /princ kafka/broker01.test.com@TEST.COM /mapuser TEST\kafka-service-account /pass * /out kafka.keytab /crypto ALL /ptype KRB5_NT_PRINCIPAL /kvno 0
  

  执行过程中按提示输入绑定的服务账号密码，生成的keytab文件直接传输到Kafka服务器即可。
• 方案2：已加入AD的Kafka服务器端生成
  首先先验证绑定账号的密码有效性，执行：

  kinit <绑定的AD账号全称，示例：kafka-service-account@TEST.COM>
  

  输入密码后如果能成功获取票据，说明密码正确，再执行ktutil生成keytab：

  ktutil
  add_entry -password -p kafka/broker01.test.com@TEST.COM -k 1 -e aes256-cts-hmac-sha1-96
  # 按提示输入绑定的AD账号密码
  add_entry -password -p kafka/broker01.test.com@TEST.COM -k 1 -e aes128-cts-hmac-sha1-96
  # 再次输入相同密码
  wkt /etc/security/keytabs/kafka.keytab
  exit
  

  注意：添加条目的加密类型需要与AD域支持的加密类型一致，若AD开启了RC4加密支持，可额外添加rc4-hmac类型的条目。

步骤3：验证keytab有效性 #

生成完成后执行以下命令验证，无需输入密码即可成功获取票据则说明keytab配置正确：

kinit -kt /etc/security/keytabs/kafka.keytab kafka/broker01.test.com@TEST.COM

Kafka侧配置注意事项 #

• kafka配置文件server.properties中填写的principal名称需要与keytab中的principal完全一致
• keytab文件权限需设置为600，所有者为Kafka进程启动用户，避免权限不足导致读取失败

内容的提问来源于stack exchange，提问作者John Nguyen