社区编辑申请
注册/登录
聊聊 Kerberos 的 kinit 命令和 ccache 机制
网络 通信技术
通过上述分析,我们知道,为解决问题,需要更改服务端的配置参数max_renewable_life,需要更改服务端上述两个 principal 的 maxrenewlife,并确保客户端指定 kinit -R 时 krbtgt 并没有过期,才能确保任务执行成功。

1. 前言

大家好,最近遇到了个 kerberos 相关问题,“客户端节点上执行 kinit -R 命令报错:KDC can't fulfill requested option while renewing credentials”, 在次跟大家分享下问题的解决方式,和背后的相关知识点,主要涉及到 kerberos 的 kinit 命令和 ccache 机制。

2. 问题现象与问题日志

  • 问题现象: 客户端执行命令 kinit -R 报错: “KDC can't fulfill requested option while renewing credentials”;
  • 问题日志:查看 KDC 服务端日志/var/log/krb5kdc.log 可知,上述报错对应的请求是 TGS_REQ,细节是 liming@TEST.COM for krbtgt/TEST.COM@TEST.COM,其错误原因是 ticket not renewable, 即 ticket 不可刷新;

3. 问题原因

那么 “ticket not renewable” 的原因又有哪些呢?主要有以下几个:

  • 服务端配置文件 /var/kerberos/krb5kdc/kdc.conf 或 /etc/krb5.conf 中对应的 realms 段中没有配置允许 renew ticket
  • 服务端生成 krbtgt 这个 principal 时,没有配置参数 maxrenewlife,即没有指定其 ticket 的最大可刷新时长
  • 服务端生成用户的 principal 时,没有配置参数 maxrenewlife,即没有指定其 ticket 的 最大可刷新时长(如报错日志中的 liming@TEST.COM)
  • 客户端上次成功登陆后,获得的 krbtgt 这个 service principal 的可刷新时间已过期,其过期原因是超过了服务端配置的 maxrenewlife(如报错日志中的krbtgt/TEST.COM@TEST.COM)
  • 客户端上次成功登陆后,用户 principal 的 ticket 已过期,其过期原因是超过了服务端配置的 ticket_lifetime,该参数一般配置为 24 h(如报错日志中的liming@TEST.COM)

4. 问题解决方案与操作步骤

通过上述分析,我们知道,为解决问题,需要更改服务端的配置参数max_renewable_life,需要更改服务端上述两个 principal 的 maxrenewlife,并确保客户端指定 kinit -R 时 krbtgt 并没有过期,才能确保任务执行成功。

  • 服务端更改或确认配置文件/var/kerberos/krb5kdc/kdc.conf 或 /etc/krb5.conf 中,对应的 realms 段中需要配置参数允许刷新:max_renewable_life;
  • 服务端更过或确认上述两个 principal 的参数 maxrenewlife,示例命令如下:

modprinc -maxrenewlife "1 week" +allow_renewable liming@TEST.COM

modprinc -maxrenewlife "1 week" +allow_renewable krbtgt/TEST.COM@TEST.COM

kadmin.local -q "getprinc krbtgt/TEST.COM@TEST.COM" | grep -i life

kadmin.local -q "getprinc liming@TEST.COM" | grep -i life

  • 上述配置修改或确认完毕后,还需要重新登录以生成新的 ticket,后续的 kinit -R 命令才能成功执行
  • 同时可以看到,改动 principal 的参数 maxrenewlife 前,klist 不提示 renew until ...,而改动 principal 的参数 maxrenewlife后,klist 会提示 renew until ....,即在次日期之前可以使用 kinit -R 刷新 ticket

5. 背景知识: kinit 命令与 ccache 机制

  • 用户在客户端通过 kinit 成功登录 kerberos 后,会将获得的 ticket-granting ticket 缓存到客户端的 ccache (credentail cache) 文件中
  • ccache 文件地址是通过配置文件 /etc/krb5.conf 中的参数 default_ccache_name来配置的,在 linux 操作系统中一般是配置为 FILE:/tmp/krb5cc_%{uid},实际对应文件 /tmp/krb5cc_0 等
  • "kinit -R" 命令,可以用来刷新 ticket-granting ticket,即 tgt
  • "kinit -R" 命令,只能在 ticket 没有过期之前,且还在 krbtgt 可刷新时间之前,刷新 ticket
  • "kinit -R" 成功刷新 ticket 之后, 会更新 ccache (credentail cache) 文件,大家可以通过 ls -al 命令查看 linux 中该文件的 ctime 确认这一点
  • kinit 登录,对应的是 AS_REQ,需要 KDC 中的 Authentication Server (AS) 校验用户身份,获得的是krbtgt,对应 kerberos 日志中的:liming@TEST.COM for krbtgt/TEST.COM@TEST.COM
  • kinit 认证完毕后,后续使用受 kerberos 保护的服务,比如登录 hiveserver2时,命令格式为:beeline -u "jdbc:hive2://uf30-2:10000/default;principal=hive/_HOST@TEST.COM", 此时在底层是一个 TGS_REQ,对应 kerberos 日志中的:liming@TEST.COM for hive/cdp2@TEST.COM
  • kinit -R 续期 tgt,对应的是 TGS_REQ, 需要 KDC 中的 Ticket Granting Server (TGS) 的响应,其效果是刷新了krbtgt,更新了 ccache 文件如 /tmp/krb5cc_0, 对应 kerberos 日志中的:liming@TEST.COM for krbtgt/TEST.COM@TEST.COM;

[root@uf30-1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/admin@CDH.COM
Valid starting Expires Service principal
11/13/2020 13:08:27 11/14/2020 13:08:27 krbtgt/CDH.COM@CDH.COM
renew until 11/20/2020 13:08:27
[root@uf30-1 ~]# kinit -R
[root@uf30-1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/admin@CDH.COM
Valid starting Expires Service principal
11/13/2020 19:38:15 11/14/2020 19:38:15 krbtgt/CDH.COM@CDH.COM
renew until 11/20/2020 13:08:27


责任编辑:武晓燕 来源: 明哥的IT随笔

同话题下的热门内容

常见的企业网络连接类型面试突击:输入URL之后会执行什么流程?

编辑推荐

FTP与SFTP两者有什么区别你的手机支持5Gwifi吗?5G上网真的很快吗?VXLAN与EVPN的结合使用VXLAN技术介绍:三层的网络来搭建虚拟的二层网络什么是通信原理?原来这么简单
我收藏的内容
点赞
收藏

51CTO技术栈公众号