IT小白

这个屌丝很懒，什么也没留下！

热门标签

【大数据安全-Kerberos】Kerberos常见问题及解决方案_gss initiate failed_client not found in kerberos database

作者：IT小白 | 2024-06-27 19:46:55

踩

client not found in kerberos database

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

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

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

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)

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

2.2.kinit 异常

kinit: KDC cannot fulfill requested option while renewing credentials

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

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

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

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开始，默认情况下未完成此操作。

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委托人不匹配的服务密钥的使用。

kinit: Preauthentication failed while getting initial credentials

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

server has invalid kerberos principal

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

kinit : Password incorrect while getting initial credentials

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

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

请求续订票证时，将续订生存期添加到krb5.conf或指定续订期限。在某些情况下，Cloudera Manager5.1.2可以防止此问题。
查看，备份和灾难恢复（BDR）无法获取可更新的Kerberos TGT

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

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

KDC: no supported encryption type

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

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

（1）

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

（2）

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

kinit: Preauthentication failed while getting initial credentials

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

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

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

2.3.LoginException

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 *来识别

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

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

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

当JCE jar在客户端计算机上不是最新的并且无法使用Kerberos 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)

为所有Principal删除require_preauth标志：kadmin：modprinc -requires_preauth PRINCNAME

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

运行Cloudera Manager主机检查器，以确认没有主机名解析问题。检查客户端和KDC上的其他主机名解析问题
在撰写本文时（Cloudera Manager 5.4.2），如果将主机包含大写字母添加到Cloudera Manager，则将使用大写字母生成Principal。而集群软件将始终尝试使用小写字母，因此它们将不匹配。每个服务器上的命令getent hosts都必须以小写形式解析该主机。
确认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)

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

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

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

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）

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

尝试连接之前，请先进行身份验证kinit。对于Mac或Windows，请参阅以下说明：

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

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

检查请求的服务的配置中是否包含诸如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

确认请求的票证是可更新的，并且KDC / KRB5是可更新的。通常，寻找Kerberos配置意味着应该拒绝该请求，例如具有不可转发配置的可转发请求等。
查看，备份和灾难恢复（BDR）无法获取可更新的Kerberos TGT

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.5.其他异常

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支持的加密类型不匹配。

Found unsupported keytype (18)

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

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。

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