【安全】Kerberos相关问题进行故障排除| 常见错误和解决方法

1.概述

转载 为了学习：Kerberos相关问题进行故障排除| 常见错误和解决方法

2.总结

可以用来帮助诊断Kerberos相关问题的原因并实施解决方案的指南。

3. 症状

单击症状链接转到相应的疑难解答部分。

2.1 Kerberos tgt

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

此消息表明一个操作尝试要求以Kerberos的user/host@realm身份认证的操作，但票据cache中没有用于user/host@realm的票据。

• 用户环境引用的策略/票证缓存文件丢失、不可读（权限）、损坏或无效
• 票证续签寿命设置为零
• 票证授予票证（TGT）不存在，因为服务A需要将命令作为服务B运行，但尚未正确配置为允许模拟服务B
• 票证更新尚未执行/未成功。这可能是由于CDH 5.3之前的HBASE或CDH5.2之前的Hive / Sentry缺陷引起的
• 该用户的凭据尚未在KDC中生成
• 执行了手动步骤，例如hadoop fs -ls，但是用户从未通过Kerberos身份验证
• Oracle JDK 6 Update 26或更早版本无法读取由MIT Kerberos 1.8.1或更高版本创建的Kerberos凭证高速缓存。
• 某些版本的Oracle JDK 8可能会遇到此问题

2.2 GSSException

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Fail to create credential. (63) - No service creds)]

• 由JDK缺陷引起
• 票证消息对于UDP协议而言太大
• 主机未正确映射到Kerberos领域

2.3 续签

Could not renew kerberos ticket in order to work around Kerberos 1.8.1 issue

票证的续签截止日期 与有效开始 日期相同，因此无法续签该票证。

2.4 HTTP身份验证

`java.io.IOException: Couldn’t setup connection for cloudera@SEC.CLOUDERA.COMHTTP Status 401 - Authentication required

在访问任何使用Kerberos加密配置的Web界面（例如Oozie作业设计器）之前，需要Kerberos HTTP身份验证（SPNEGO）

2.5 网络连接问题

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Receive timed out)]

网络连接问题
这可能是由于使用UDP与KDC通信引起的

2.6 LOCKED_OUT

`Exception in thread "main" java.lang.IllegalArgumentException: Couldn't setup Kerberos authentication 
Caused by: javax.security.auth.login.LoginException: Clients credentials have been revoked (18) - LOCKED_OUT 
org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(UserGroupInformation.java:816)

Caused by: KrbException: Clients credentials have been revoked (18) - LOCKED_OUT 

Caused by: KrbException: Identifier doesn't match expected value (906)
Keytab contains no suitable keys for hue/server1.aaa.bbb.net@REALM.NET 
while getting initial credentialsor:Couldn't reinit from keytab!

Keytab中的user/host@realm与尝试针对领域进行身份验证的user/hostname不匹配

2.7 GSS-API leve

org.apache.hadoop.security.authentication.client.AuthenticationException: /GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))

用户或服务正在尝试使用旧的Kerberos keytab进行身份验证。
自发布此keytab以来，有人重新生成了Principal，从而使key的版本值增加了。如果有人使用Cloudera Manager重新生成key但不重新启动服务，或者对于尚未分发新keytab的手动配置，可能会发生这种情况。

某些服务需要一些密钥，例如MapReduce / HDFS需要HTTP密钥。如果重新生成了HDFS服务密钥，则HTTP的版本也会增加，并且更新后的密钥必须同时部署到这两个服务并重新启动
kinit: KDC cannot fulfill requested option while renewing credentials
已请求续订有效期为零的票证。如果在kinit命令中未指定，则生存期将从krb5.conf中获取，如果不存在renew_lifetime，则生存期默认为零。
您的KDC上的krbtgt服务Principal的更新生命周期为0。

2.8 UNKNOWN_SERVER

GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)

hostname或要访问的URL与keytab中列出的主机之间发生主机名不匹配。造成这种情况的原因多种多样，包括但不限于：

• 多网卡（NIC）服务器，以使来自主机的数据包的IP地址与通过主机解析返回的IP不匹配
• 负载平衡器和后续的主机名解析问题
• DNS和主机名解析问题/不一致
• 反向DNS（必需）主机名解析问题/不一致
• 在krb5.conf中主机正在映射到参数[domain_realm]的错误域，这或者是通过其他的krb5.conf配置，或者是通过KDC配置。默认参数情况下，除非使用[domain_realm]等进行显式配置，否则主机名（例如：“ crash.EXAMPLE.com ”）将映射到域“ EXAMPLE.com ” 。请参见MIT Kerberos文档：[domain_realm]
• 如果尝试在Cloudera Manager中执行“ Generate Credentials ”步骤（在更高版本中重命名为“ Generate Missing Credentials ”）时发生此错误，则可能是由于导入到Cloudera Manager数据库中的管理员帐户详细信息不再与主机匹配，例如Cloudera Manager服务器的主机名在上一次导入后随后更改了。

2.9 GSSHeader

GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

• 令牌中的主机名必须是可解析的，并且与主机身份验证匹配
• 请参阅知识文章，Error: “HTTP Status 401” when Accessing the Oozie WebUI
• JDK8版本u51之前的缺陷

2.10 allowed to impersonate hdfs

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): / User: hdfs/host1.cloudera.com@CLOUDERA.COM is not allowed to impersonate hdfs

服务A需要以服务B的身份运行命令，但尚未正确配置为允许模拟服务B。

2.11

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException:java.io.IOException: Tgt generation for principal ‘hdfs/host1.testdomain@MYREALM’ / failed with exit code '1’kinit: KDC can’t fulfill requested option while renewing credentials

发出了不允许的请求，例如尝试续订不可续签的票证。

2.12 enctype-related

enctype-related errors

提及“ enctype ”的错误通常表示Principal、客户端、服务器和KDC支持的加密类型不匹配。

2.13 Request is a replay

GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level / (Mechanism level: Request is a replay (34)]

• KDC会在短时间内看到来自同一Principal名称的多个身份验证请求，并拒绝该请求以防止“中间人”攻击
• 如果在多个主机/服务上使用了相同的Principal/key，或者由于主机之间的时钟变化，可能会发生这种情况

2.14 KDC for realm

kinit: Cannot contact any KDC for realm ‘EXAMPLE.COM’ while getting initial credentials

• 客户端和KDC之间的网络问题
• krb5.conf中的KDC详细信息不正确

2.15 CLIENT_NOT_FOUND

Caused by: javax.security.auth.login.LoginException: Client not found in Kerberos database (6) - CLIENT_NOT_FOUND

• 列出的Principal（例如HTTP / host @ realm）在keytab中不存在
• 我们要连接的Principal/主机的大小写与keytab中的Principal/主机的大小写不匹配（Kerberos区分大小写）
• Principal在KDC中不存在。注意：有时会发生这种情况，因为在一个AD实例中配置了Principal，但是您正在查询另一个（可能是通过VIP），并且Principal尚未被复制。
• Active Directory KDC中存在同一Principal的多个条目（这会中断后续的kinit尝试）

2.16 Checksum failed

javax.security.auth.login.LoginException: Checksum failed或者GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

• 尝试使用与KDC中的条目不匹配的keytab来kinit。通常，当keytab很旧时会发生这种情况，这些旧的Principal已被删除，新的Principal已创建，因此旧的Principal不再有效。
• 如果您尝试使用Hive以外的用户从Beeline登录到Kerberized集群，则可以看到此信息。
• 当Namenode尝试调用HTTP URL以获取新的fsimage（作为检查点过程的一部分）时，或者在从Journal节点读取编辑时启动时，也可以在Active Namenode日志中观察到此错误。发生这种情况的原因是Active Directory KDC中有重复的HTTP / <主机名>条目，或者存在小写的http / <主机名>条目。可以通过运行setspn -q * / * host-name *来识别

2.17 KDC: no supported encryption type

KDC: no supported encryption type

• 在krb5.conf中定义的加密类型（如果部署了由Cloudera Manager集成的Cloudera Manager的Kerberos）不匹配您的KDC提供的加密类型
• KDC中配置的Principal的加密类型和krb5.conf中的加密类型不匹配
• 群集已配置为仅支持128/256位加密，但是尚未为AD中的Principal启用此功能。
• 注意：从Cloudera Manager5.4.2开始，默认情况下未完成此操作。

2.18 obtain password

javax.security.auth.login.LoginException: Unable to obtain password from user

• 当代码无法在keytab中找到匹配条目以获取密码时，通常会发生此错误。由于CDH中的服务不是交互式的，因此在此示例中，密码请求失败并导致显示消息。
• 这可以表明无法读取keytab。
• 如果keytab中的所有条目均不可用，例如，如果keytab仅具有aes256但未将无限强度的加密jar添加到群集中，则也会发生这种情况。

2.19 unsupported keytype

Found unsupported keytype (18)

• 仅在为服务启用krb5调试（例如-Dsun.security.krb5.debug = true）后，您才可能看到此错误。
• 当keytab中的某个密钥无法被代码使用时，就会发生此错误。通常，当存在256位密钥但代码没有可用的无限强度库时，会发生这种情况。通常，当不存在策略文件，权限不正确，不匹配的JDK（安装到群集未使用的JDK），不匹配的策略文件集（例如JDK 6）安装到JDK 7环境中时，就会发生这种情况。

2.20 BAD_ENCRYPTION_TYPE

kinit: KDC has no support for encryption type while getting initial credentials或者 KDC has no support for encryption type (14) - BAD_ENCRYPTION_TYPE

尝试在Cloudera Manager中导入Kerberos帐户管理器凭据时，或者在KDC中配置与tgtPrincipal中存在的加密类型不匹配的加密类型（例如krbtgt/CLOUDERA@CLOUDERA）之后，使用向导启用Kerberos时，您可能会看到此错误。。同时启动服务，其中在该enctypes也会发生这种情况的krbtgt委托人不匹配的服务密钥的使用。

2.21 PROCESS_TGS

GSSException: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31) - PROCESS_TGS)]; Host Details : local host is: “myhost61.mycompany.com/10.XX.XX.XXX”; destination host is: “myhost002.mycompany.com”:8020;…Caused by: KrbException: Identifier doesn’t match expected value (906)

尝试使用请求的KDC中存在的keytab中的Principal名称来kinit，但该keytab是从其他KDC生成的。尝试在使用Kerberos的群集（例如throughBDR）之间复制数据时，这两个群集都使用相同的领域名称，但使用不同的KDC

2.22 No rules applie

Diagnostics: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider...Caused by: org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: No rules applied to myuser@REALM.COM

• hadoop.security.auth_to_local规则不足以将kerberosPrincipal映射到本地Linux用户。默认情况下，auth_to_local规则将删除Principal的@REALM.COM部分，但是，如果未正确指定它们，或者它们不足以提取本地用户，则可能会出现此问题。
• 当前用户无法读取krb5.conf。

总结

可以用来帮助诊断Kerberos相关问题的原因并实施解决方案的指南。

症状

单击症状链接转到相应的疑难解答部分。

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

此消息表明一个操作尝试要求以Kerberos的user/host@realm身份认证的操作，但票据cache中没有用于user/host@realm的票据。

• 用户环境引用的策略/票证缓存文件丢失、不可读（权限）、损坏或无效
• 票证续签寿命设置为零
• 票证授予票证（TGT）不存在，因为服务A需要将命令作为服务B运行，但尚未正确配置为允许模拟服务B
• 票证更新尚未执行/未成功。这可能是由于CDH 5.3之前的HBASE或CDH5.2之前的Hive / Sentry缺陷引起的
• 该用户的凭据尚未在KDC中生成
• 执行了手动步骤，例如hadoop fs -ls，但是用户从未通过Kerberos身份验证
• Oracle JDK 6 Update 26或更早版本无法读取由MIT Kerberos 1.8.1或更高版本创建的Kerberos凭证高速缓存。
• 某些版本的Oracle JDK 8可能会遇到此问题

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Fail to create credential. (63) - No service creds)]

• 由JDK缺陷引起
• 票证消息对于UDP协议而言太大
• 主机未正确映射到Kerberos领域

Could not renew kerberos ticket in order to work around Kerberos 1.8.1 issue

票证的续签截止日期 与有效开始 日期相同，因此无法续签该票证。

java.io.IOException: Couldn't setup connection for cloudera@SEC.CLOUDERA.COMHTTP Status 401 - Authentication required

在访问任何使用Kerberos加密配置的Web界面（例如Oozie作业设计器）之前，需要Kerberos HTTP身份验证（SPNEGO）

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Receive timed out)]

• 网络连接问题
• 这可能是由于使用UDP与KDC通信引起的

Exception in thread "main" java.lang.IllegalArgumentException: Couldn't setup Kerberos authentication Caused by: javax.security.auth.login.LoginException: Clients credentials have been revoked (18) - LOCKED_OUT org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(UserGroupInformation.java:816)Caused by: KrbException: Clients credentials have been revoked (18) - LOCKED_OUT Caused by: KrbException: Identifier doesn't match expected value (906)

Keytab contains no suitable keys for hue/server1.aaa.bbb.net@REALM.NET while getting initial credentialsor:Couldn't reinit from keytab!

Keytab中的user/host@realm与尝试针对领域进行身份验证的user/hostname不匹配

org.apache.hadoop.security.authentication.client.AuthenticationException: /GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))

• 用户或服务正在尝试使用旧的Kerberos keytab进行身份验证。

自发布此keytab以来，有人重新生成了Principal，从而使key的版本值增加了。如果有人使用Cloudera Manager重新生成key但不重新启动服务，或者对于尚未分发新keytab的手动配置，可能会发生这种情况。

• 某些服务需要一些密钥，例如MapReduce / HDFS需要HTTP密钥。如果重新生成了HDFS服务密钥，则HTTP的版本也会增加，并且更新后的密钥必须同时部署到这两个服务并重新启动

kinit: KDC cannot fulfill requested option while renewing credentials

• 已请求续订有效期为零的票证。如果在kinit命令中未指定，则生存期将从krb5.conf中获取，如果不存在renew_lifetime，则生存期默认为零。
• 您的KDC上的krbtgt服务Principal的更新生命周期为0。

GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)

hostname或要访问的URL与keytab中列出的主机之间发生主机名不匹配。造成这种情况的原因多种多样，包括但不限于：

1. 多网卡（NIC）服务器，以使来自主机的数据包的IP地址与通过主机解析返回的IP不匹配
2. 负载平衡器和后续的主机名解析问题
3. DNS和主机名解析问题/不一致
4. 反向DNS（必需）主机名解析问题/不一致
5. 在krb5.conf中主机正在映射到参数[domain_realm]的错误域，这或者是通过其他的krb5.conf配置，或者是通过KDC配置。默认参数情况下，除非使用[domain_realm]等进行显式配置，否则主机名（例如：“ crash.EXAMPLE.com ”）将映射到域“ EXAMPLE.com ” 。请参见MIT Kerberos文档：[domain_realm]
6. 如果尝试在Cloudera Manager中执行“ Generate Credentials ”步骤（在更高版本中重命名为“ Generate Missing Credentials ”）时发生此错误，则可能是由于导入到Cloudera Manager数据库中的管理员帐户详细信息不再与主机匹配，例如Cloudera Manager服务器的主机名在上一次导入后随后更改了。

GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

• 令牌中的主机名必须是可解析的，并且与主机身份验证匹配
• 请参阅知识文章，Error: "HTTP Status 401" when Accessing the Oozie WebUI
• JDK8版本u51之前的缺陷

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): / User: hdfs/host1.cloudera.com@CLOUDERA.COM is not allowed to impersonate hdfs

服务A需要以服务B的身份运行命令，但尚未正确配置为允许模拟服务B。

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException:java.io.IOException: Tgt generation for principal 'hdfs/host1.testdomain@MYREALM' / failed with exit code '1'kinit: KDC can't fulfill requested option while renewing credentials

发出了不允许的请求，例如尝试续订不可续签的票证。

enctype-related errors

提及“ enctype ”的错误通常表示Principal、客户端、服务器和KDC支持的加密类型不匹配。

GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level / (Mechanism level: Request is a replay (34)]

• KDC会在短时间内看到来自同一Principal名称的多个身份验证请求，并拒绝该请求以防止“中间人”攻击
• 如果在多个主机/服务上使用了相同的Principal/key，或者由于主机之间的时钟变化，可能会发生这种情况

kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials

• 客户端和KDC之间的网络问题
• krb5.conf中的KDC详细信息不正确

Caused by: javax.security.auth.login.LoginException: Client not found in Kerberos database (6) - CLIENT_NOT_FOUND

• 列出的Principal（例如HTTP / host @ realm）在keytab中不存在
• 我们要连接的Principal/主机的大小写与keytab中的Principal/主机的大小写不匹配（Kerberos区分大小写）
• Principal在KDC中不存在。注意：有时会发生这种情况，因为在一个AD实例中配置了Principal，但是您正在查询另一个（可能是通过VIP），并且Principal尚未被复制。
• Active Directory KDC中存在同一Principal的多个条目（这会中断后续的kinit尝试）

javax.security.auth.login.LoginException: Checksum failed或者GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

• 尝试使用与KDC中的条目不匹配的keytab来kinit。通常，当keytab很旧时会发生这种情况，这些旧的Principal已被删除，新的Principal已创建，因此旧的Principal不再有效。
• 如果您尝试使用Hive以外的用户从Beeline登录到Kerberized集群，则可以看到此信息。
• 当Namenode尝试调用HTTP URL以获取新的fsimage（作为检查点过程的一部分）时，或者在从Journal节点读取编辑时启动时，也可以在Active Namenode日志中观察到此错误。发生这种情况的原因是Active Directory KDC中有重复的HTTP / <主机名>条目，或者存在小写的http / <主机名>条目。可以通过运行setspn -q * / * host-name *来识别

KDC: no supported encryption type

• 在krb5.conf中定义的加密类型（如果部署了由Cloudera Manager集成的Cloudera Manager的Kerberos）不匹配您的KDC提供的加密类型
• KDC中配置的Principal的加密类型和krb5.conf中的加密类型不匹配
• 群集已配置为仅支持128/256位加密，但是尚未为AD中的Principal启用此功能。

注意：从Cloudera Manager5.4.2开始，默认情况下未完成此操作。

javax.security.auth.login.LoginException: Unable to obtain password from user

• 当代码无法在keytab中找到匹配条目以获取密码时，通常会发生此错误。由于CDH中的服务不是交互式的，因此在此示例中，密码请求失败并导致显示消息。
• 这可以表明无法读取keytab。
• 如果keytab中的所有条目均不可用，例如，如果keytab仅具有aes256但未将无限强度的加密jar添加到群集中，则也会发生这种情况。

Found unsupported keytype (18)

• 仅在为服务启用krb5调试（例如-Dsun.security.krb5.debug = true）后，您才可能看到此错误。
• 当keytab中的某个密钥无法被代码使用时，就会发生此错误。通常，当存在256位密钥但代码没有可用的无限强度库时，会发生这种情况。通常，当不存在策略文件，权限不正确，不匹配的JDK（安装到群集未使用的JDK），不匹配的策略文件集（例如JDK 6）安装到JDK 7环境中时，就会发生这种情况。

kinit: KDC has no support for encryption type while getting initial credentials或者 KDC has no support for encryption type (14) - BAD_ENCRYPTION_TYPE

尝试在Cloudera Manager中导入Kerberos帐户管理器凭据时，或者在KDC中配置与tgtPrincipal中存在的加密类型不匹配的加密类型（例如krbtgt/CLOUDERA@CLOUDERA）之后，使用向导启用Kerberos时，您可能会看到此错误。。同时启动服务，其中在该enctypes也会发生这种情况的krbtgt委托人不匹配的服务密钥的使用。

GSSException: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31) - PROCESS_TGS)]; Host Details : local host is: "myhost61.mycompany.com/10.XX.XX.XXX"; destination host is: "myhost002.mycompany.com":8020;...Caused by: KrbException: Identifier doesn't match expected value (906)

• 尝试使用请求的KDC中存在的keytab中的Principal名称来kinit，但该keytab是从其他KDC生成的。尝试在使用Kerberos的群集（例如throughBDR）之间复制数据时，这两个群集都使用相同的领域名称，但使用不同的KDC

Diagnostics: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider...Caused by: org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: No rules applied to myuser@REALM.COM

• hadoop.security.auth_to_local规则不足以将kerberosPrincipal映射到本地Linux用户。默认情况下，auth_to_local规则将删除Principal的@REALM.COM部分，但是，如果未正确指定它们，或者它们不足以提取本地用户，则可能会出现此问题。
• 当前用户无法读取krb5.conf。

kinit: Preauthentication failed while getting initial credentials

• 此问题的最常见原因是使用了错误的密码。例如，这可能是因为在导入Cloudera Manager凭据时或在keytab生成后更改了Principal的密码时（例如，如果重新生成了Principal，但keytab尚未更新）

server has invalid kerberos principal

1. 由于主机解析问题，因此可以看到此错误，因为Kerberos选择确保IP地址、主机名和Principal都对齐
2. 对于BDR，可能会由于https://issues.apache.org/jira/browse/HDFS-7546而看到此错误

kinit : Password incorrect while getting initial credentials

• 当所使用的kerberoskeytab中的密码与存储在KDC中的密码不匹配时，会发生此错误。发生这种情况的原因有多种，例如使用了一个旧的keytab进行初始化（此后更改了密码或重新生成了Principal，则该密码已在数据库中更改过，用户的密码已在数据库中更改过），等等。经常会出现此错误。同样，通常是由于用户干预，Cloudera Manager数据库中的Principal与KDC不同步时

javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication

• 当JCE jar在客户端计算机上不是最新的并且无法使用Kerberos KDC提供的加密密钥时，就会发生此问题。

GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)

• 如果正向和反向DNS解析不一致，则会发生这种情况。

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken): Token has expired at org.apache.hadoop.hbase.security.HBaseSaslRpcClient.readStatus

• 如果发生此异常，则抛出

1. 作业的运行时间超过“ hbase.auth.token.max.lifetime”（Region Server配置，默认情况下为7天），并且
2. 一个长时间运行的非作业进程不必要地获取HBase身份验证令牌，通过keytab或票证高速缓存登录名绕过Kerberos身份验证方法的可更新用法，并将其生存期限制为“ hbase.auth.token.max.lifetime”价值。

适用于

• CDH
• 安全
• Kerberos

教程

症状部分按编号列出了问题，并在此处用相同的编号列出了相应的解决方案。

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided Mechanism level: Failed to find any Kerberos TGT]

1. 确保策略文件存在并且可由当前用户访问。cksum将文件与已知的工作副本进行比较，并在必要时进行替换：

$JAVA_HOME/jre/lib/security/US_export_policy.jar

$JAVA_HOME/jre/lib/security/local_policy.jar

1. 确保为KDC和Principal设置了最大可再生寿命。请参阅知识文章， Impala服务无法以错误开头：“未能找到任何Kerberos tgt”
2. 检查服务的配置，其中包含用户可以模拟其他用户的条目。通常列为proxyusers或类似配置。
3. 升级到CDH 5.3。

注意：请参阅以下知识文章：

• HBase Canary测试无法更新导致HBase的Kerberos票证：SASL身份验证失败消息
• HiveServer2定期无法使用Sentry运行查询

1. 通过Cloudera Manager为指定用户生成凭证。
2. 以具有执行所需命令权限的用户身份运行kinit
3. 更新JDK。请参阅《Cloudera Security：身份验证问题故障排除》
4. 安装JDK 8版本51或更高版本

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to create credential. (63) - No service creds)]

1. 升级JDK：Cross Realm Authentication with Cluster Services Fail with GSS error (63) due to KRB/JDK 6 Bug
2. 切换到TCP通过以下设置在krb5.conf中：
3. udp_preference_limit = 1
4. 确保存在krb5.conf的[domain_realm]节中的任一条目，以将请求的Principal的主机映射到Kerberos领域，或者确保[libdefaults]中的default_realm条目存在且与该Principal匹配

请参阅《Cloudera Security：身份验证问题故障排除》

Could not renew Kerberos ticket in order to work around Kerberos 1.8.1 issue

1. 在KDC中设置适当的续订期限。看， Hue Kerberos票证续订程序无法启动| 错误：无法续订Kerberos票证以解决Kerberos 1.8.1问题

java.io.IOException: Couldn't setup connection for cloudera@SEC.CLOUDERA.COM HTTP Status 401 - Authentication required

1. 尝试连接之前，请先进行身份验证/ kinit。

对于Mac或Windows，请参阅以下说明：

• 在Mac OS上为Safari配置SPNEGO Kerberos身份验证
• 从Windows客户端配置SPNEGO（Kerberos）身份验证到群集HTTP服务

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Receive timed out)]

1. 配置Kerberos客户端配置krb5.conf以使用TCP和/或调查网络问题。请参阅在与KDC通信时强制Kerberos客户端使用TCP

Exception in thread "main" java.lang.IllegalArgumentException: Couldn't setup Kerberos authentication Caused by: javax.security.auth.login.LoginException: Clients credentials have been revoked (18) - LOCKED_OUT org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(UserGroupInformation.java:816) Caused by: KrbException: Clients credentials have been revoked (18) - LOCKED_OUT Caused by: KrbException: Identifier doesn't match expected value (906)

1. 为所有Principal删除require_preauth标志：

kadmin：modprinc -requires_preauth PRINCNAME

注意：请参阅，Beeswax和/或Kerberos票证续订服务失败，并出现以下错误：“凭据被锁定”

or hue/server1.example.net@REALM.NET while getting initial credentials or:Couldn't reinit from keytab!

1. 确保尝试进行身份验证的主机的主机名解析与客户端和KDC的密钥选项卡中列出的Principal匹配

org.apache.hadoop.security.authentication.client.AuthenticationException: GSSException: Failure unspecified at GSS-API level (Mechanism level:Specified version of key is not available (44))

1. 根据需要重新分配密钥，然后重新启动过程。

请参阅使用kinit和klist对Hadoop Kerberos问题进行故障排除

kinit: KDC can't fulfill requested option while renewing credentials.

1. 请求续订票证时，将续订生存期添加到krb5.conf或指定续订期限。在某些情况下，Cloudera Manager5.1.2可以防止此问题。

查看，备份和灾难恢复（BDR）无法获取可更新的Kerberos TGT

GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database(7) - UNKNOWN_SERVER

a-d:确保服务的主机名，URL，通信的NIC和keytab匹配。请参阅以下知识文章：

• 运行Oozie CLI命令以通过负载均衡器连接到Oozie服务器会出现身份验证错误
• 多宿主Kerberized（AD）群集
  • 确保将可选值[domain_realm]设置为将主机映射到正确的域，或者如果默认领域足够，则删除这些条目。
  • 查看是否使用了列出的Kerberos手册链接中提到的任何其他配置，如果是，则使用这些值是否合适。
• 运行 Cloudera Manager主机检查器 以收集有关主机网络和DNS的信息

e．从Cloudera Manager中，导航到 管理>安全性 ，然后单击 导入Kerberos帐户管理器凭据以将管理凭据重新导入到Cloudera Manager中。

GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

1. 确保主机名解析为与KDC和其他服务通信的服务的IP。查看：错误：访问Oozie WebUI时出现“ HTTP状态401”
2. 至少升级到JDK8的51更新

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): User: hdfs/host1.cloudera.com@CLOUDERA.COM is not allowed to impersonate hdfs

1. 检查请求的服务的配置中是否包含诸如hadoop.proxyuser.hdfs.*之类的条目，或查看以下文章以获取更多信息： 启用Kerberos的BDR HDFS复制失败，并显示“不允许模拟hdfs”异常

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): java.io.IOException: Tgt generation for principal 'hdfs/host1.testdomain@MYREALM' failed with exit code '1' kinit: KDC can't fulfill requested option while renewing credentials

1. 确认请求的票证是可更新的，并且KDC / KRB5是可更新的。
2. 通常，寻找Kerberos配置意味着应该拒绝该请求，例如具有不可转发配置的可转发请求等。

查看， 备份和灾难恢复（BDR）无法获取可更新的Kerberos TGT

"enctype"related errors

1. 在所有主机上检查kdc.conf或krb5.conf的supported_enctypes字段。
2. 如果使用的是AES256，请确保已将无限强度策略文件添加到JDK。
3. 检查已为KDC中的特定Principal配置了哪些加密类型。

请参阅《Cloudera Security：对身份验证问题进行故障排除》

GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Request is a replay (34))]

• 对每个服务/主机组合使用唯一的Principal。例如，而不是myservice@EXAMPLE.COM，使用myservice/host123.example.com@EXAMPLE.COM。
• 确保已安装并运行网络时间协议（NTP），以便同步所有主机时钟

请参阅《 Cloudera Security：对身份验证问题进行故障排除》

kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials

1. 确认KDC处于联机状态，并且可以在适当的端口（默认为端口88）上访问它
2. 确认krb5.conf中的KDC地址正确

javax.security.auth.login.LoginException: Client not found in Kerberos database (6) - CLIENT_NOT_FOUND

1. 运行Cloudera Manager主机检查器，以确认没有主机名解析问题。检查客户端和KDC上的其他主机名解析问题
2. 在撰写本文时（Cloudera Manager 5.4.2），如果将主机包含大写字母添加到Cloudera Manager，则将使用大写字母生成Principal。而集群软件将始终尝试使用小写字母，因此它们将不匹配。每个服务器上的命令getent hosts都必须以小写形式解析该主机。
3. 确认Principal存在于KDC中，并在必要时生成。如果使用AD，则仅配置和查询单个AD实例。 请与您的Active Directory管理员联系，以手动删除所有重复的Principal。使用Cloudera Manager的UI重新生成这些Principal（“管理”>“安全性”>“ Kerberos凭据”>“重新生成所选内容”）

javax.security.auth.login.LoginException: Checksum failed OR GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

1. 确认正在使用最新的Principal/keytab。如有必要，重新生成Principal和/或重新启动服务
2. kinit作为您将在Hive中使用的帐户的用户，然后在beeline中与以下用户连接：!connect jdbc:hive2://localhost:10000/default;principal=hive/quickstart.cloudera@SEC.CLOUDERA.COM
3. 识别（在Windows上使用setspn -q * / *主机名*）并删除KDC中任何重复的或小写的HTTP /主机名Principal。这将要求客户联系其广告管理员

KDC: no supported encryption type

1. 更改群集加密类型。如果集群krb5.conf由Cloudera Manager管理，则可以在Cloudera Manager GUI中完成。或者，更改KDC支持的加密类型
2. 配置Principal以接受所需的加密类型，或将群集更改为使用不同的加密类型。通常，这将发生在MIT而非AD
3. 在Active Directory中，对于每个Principal，选择以下复选框：此帐户支持在Active Directory中创建的每个帐户的“此帐户支持Kerberos AES 128位加密 和此帐户支持Kerberos AES 256位加密 ”，或更改群集上的Kerberos配置。使用除AES 128/256以外的加密。

javax.security.auth.login.LoginException: Unable to obtain password from user

确保keytab存在并且具有正确的权限，以便尝试使用它的用户可以读取它

1. 确保正确安装了与JDK相匹配的无限强度策略文件的正确版本
2. 确保对策略文件（位于jdk目录中，例如/usr/java/jdk1.7.0_67-cloudera/jre/lib/security/）的许可权能够被所有用户读取。
3. 确保文件已部署到集群软件正在使用的JDK中
4. 尝试使用kinit使用keytab，以确定此keytab包含Principal，将与当前的工作KDC/KRB5的conf

Found unsupported keytype(18)

1. 确保正确安装了与JDK相匹配的无限强度策略文件的正确版本
2. 确保对策略文件（位于jdk目录中，例如/usr/java/jdk1.7.0_67-cloudera/jre/lib/security/）的许可权能够被所有用户读取。
3. 确保文件已部署到集群软件正在使用的jdk中
4. 有关详细信息，使用以下的（链接以匹配关键字类型号18在该实例中）将其加密类型http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xml（AES256-CTS-HMAC-此示例为sha1-96）

kinit: KDC has no support for encryption type while getting initial credentials OR KDC has no support for encryption type (14) - BAD_ENCRYPTION_TYPE

A1

1. 在KDC服务器上的kadmin.local工具中使用getprinckrbtgt/CLOUDERA@CLOUDERA进行确认
2. 在kdc.conf中编辑kdc支持的加密类型列表（注意：进行更改后，您可能需要重新启动kdc或kadmin.local）。
3. 使用delprinc krbtgt/CLOUDERA@CLOUDERA删除并重新创建Principal，然后添加princ krbtgt/CLOUDERA@CLOUDERA来更改Principal的编码类型
4. 在Cloudera Manager中重试失败的步骤

或者

A2

1. 在KDC服务器上的kadmin.local工具中使用getprinckrbtgt/CLOUDERA@CLOUDERA进行确认
2. 将其他加密类型添加到Cloudera Manager中的受支持列表中

GSSException: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31) - PROCESS_TGS)]; Host Details : local host is: "myhost61.mycompany.com/10.XX.XX.XXX"; destination host is: "myhost002.mycompany.com":8020; ... Caused by: KrbException: Identifier doesn't match expected value (906)

1. 确认所有主机上的krb5.conf设置都将查找引用到正确的KDC
2. 对于涉及在群集之间进行复制的方案，请对两个领域使用一个KDC，或者在其中一个群集上更改领域名称，然后重新创建所有Principal

Diagnostics: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider ... Caused by: org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: No rules applied to myuser@REALM.COM

1. 更正auth_to_local规则的所有问题，并确保最新的规则已作为客户端配置推出，例如替代方案--display hadoop-conf显示的目录中存在的core-site.xml文件。
2. 确保用户可以读取/etc/krb5.conf，并确保其环境变量确实设置了变量以覆盖krb5.conf的位置。

org.apache.hadoop.security.authentication.util.KerberosName $ NoMatchingRule：没有规则适用于myuser@REALM.COM

注：通常打印这些错误代码是可用src.zip，可与你的JDK的部署。例如：Krb5LoginModule.java

kinit: Preauthentication failed while getting initial credentials

1. 为尝试的步骤提供正确的密码（kinit，导入Cloudera Manager帐户凭据。）
2. 重新启动服务

如果凭据已更新，Cloudera Manager将推出新的keytab。

1. 如果重新启动服务不能解决问题，请确定是否已从Cloudera Manager控件外部更新了凭据。

server has invalid kerberos principal

1. 通过更新/etc/hosts，dns和/或/etc/resolv.conf来纠正所有主机解析问题。在继续之前，请确保Cloudera Manager中的主机检查器显示所有主机解析均成功，因为这将确认您的集群已正确配置了主机>检查所有主机
2. dfs.namenode.kerberos.principal.pattern必须在CDH5.4.5之前的HDFS for BDR和Hive复制的安全阀中通过安全阀设置为*，即使在更高版本上也是如此。

原文链接：https://my.cloudera.com/knowledge/Troubleshooting-Kerberos-Related-Issues–Common-Errors-and?id=76192