我在一个完全封闭的系统中管理一个使用Kerberos的Hortonworks (Ambari)安装，这是一个相当不令人羡慕的位置。
问题是:
我发现在服务器x上的keytab文件(让我们称之为foo)不一致:
$klist -kte /etc/security/keytabs/foo.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
12 10/21/15 16:24:27 foo@myrealm (xxxxxxxxxxxxx)
12 10/21/15 16:24:27 foo@myrealm (xxxxxxxxxxxxx)
在free-ipa服务器上，运行以下命令:
$ kadmin.local -q 'get_principal foo'
Authenticating as foo with password.
Principal:
Expiration date:
Last password change:
Password expiration date: [none]
Maximum ticket life:
Maximum renewable life:
Last modified: xxxxx (foo)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 4
Key: vno 21, abs-my-security-type, xxxxxx
Key: xxxxxxx
Key: xxxxxxx
Key: xxxxxxx
[snip]
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
"for foo"的版本不同。在freeipa服务器上的版本21。
我已经发现了"IPA -getkeytab"，它会给我一个keytab，但是增加版本号(在IPA服务器上)，每当我运行它。
我的ipa-getkeytab版本没有-r，——retrieve开关(保留版本)。
我需要在7个服务器(Hadoop节点)上获得这个keytab。我不能使用scp, ssh作为封闭网络。
是否有一种方法为我创建(拉foo keytab) 本地不增加版本号?
:0/
英里。
如果您的ipa-getkeytab版本不支持-r选项检索keytab，那么您唯一的其他选择是在一台服务器上检索keytab一次并将它们安全地传输到其他服务器。
对不起，没有其他选择。FreeIPA实现的KDC数据库驱动程序(DAL驱动程序)不允许为远程kadmin连接分配特定的管理权限，因此您甚至不能执行'getprinc'或' listprins '命令。
Kerberos keytab故障处理
A keytab是一个包含Kerberos主体对和加密密钥(从Kerberos密码派生)的文件。您可以使用keytab文件使用Kerberos对各种远程系统进行身份验证，而无需输入密码。
Keytab文件通常用于允许脚本使用Kerberos自动身份验证，而不需要人工交互或访问存储在纯文本文件中的密码。
Kerberos keytab包含"版本号"
保存在keytab文件中的版本必须与 Kerberos内部的版本一致。问题中的ERROR就是由这种情况引起的。
您需要能够排除keytab文件和Kerberos的故障。
Keytab文件-(在Hortonworks/Ambari中)这些文件存储在/etc/security/keytabs目录:
[root@box keytabs]# ls -ltr
total 24
-r--r-----. 1 hdfs hadoop 1054 Oct 26 14:24 foo.keytab
一个"修复"foo.keytab的实际例子。
使用klist命令显示存储的主体和版本(KVNO):
$ sudo su -
[root@box ~]# cd /etc/security/keytabs/
[root@box keytabs]# klist -kte foo.keytab
Keytab name: FILE:hdfs.headless.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
27 10/26/15 14:08:16 foo@principal(******)
27 10/26/15 14:08:17 foo@principal(******)
27 10/26/15 14:08:17 foo@principal (******)
27 10/26/15 14:08:17 foo@principal(******)
存储在foo中的主体。keytab的版本号为27。
比较Kerberos中的版本号
使用kadmin。local命令查询Kerberos原则(在Kerberos/freeipa机器上):
[root@kerbbox ~]# kadmin.local
Authenticating as principal admin/admin@***** with password.
kadmin.local: getprinc foo@principal
Principal: foo@principal
Expiration date: [never]
Last password change: Mon Oct 26 14:08:17 GMT 2015
Password expiration date: Tue Jan 19 14:19:33 GMT 2016
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Oct 26 14:08:17 GMT 2015 (admin/admin@*********)
Last successful authentication: Mon Oct 26 14:36:33 GMT 2015
Last failed authentication: Mon Oct 26 12:33:14 GMT 2015
Failed password attempts: 0
Number of keys: 4
Key: vno 34, ******, *****
Key: vno 34, ******, *****
Key: vno 34, ******, *****
Key: vno 34, ******, *****
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local:
kadmin.local:
使用getprinc命令获取详细信息:
foo@principal (version 34)
检查版本号(在keytab文件和Kerberos中)，确保它们是相同的。
如果keytab文件中的版本号不同(与 Kerberos中的不同)。您需要重新创建(foo.keytab)。
要检查keytab中有哪些原则，请使用klist -kte keytab file命令
创建foo。keytab文件ktadd命令:
[root@kerbbox ~]# kadmin.local ktadd -k /root/foo.keytab foo@principal示例输出(版本11用于foo@principal):
11 10/09/15 14:41:58 foo@principal (*******) 11 10/09/15 14:41:58 foo@principal (*******) 11 10/09/15 14:41:58 foo@principal (*******) 11 10/09/15 14:41:58 foo@principal (*******)每次运行ktadd命令时，(原理的)版本号将递增。
复制foo。keytab到集群中的服务器，并确保保留权限/所有权:
# chmod 440 foo.keytab # chown hdfs:hadoop foo.keytab # klist -kte hdfs.headless.keytab # ls -ltr -r--r-----. 1 hdfs hadoop 1054 Oct 26 14:24 foo.keytabkeytab中的版本号需要和kerberos中的版本号保持一致
重启Ambari服务
你会看到一个"绿色"的Ambari web-ui。