网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
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
[Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)]
如果正向和反向DNS解析不一致,则会发生这种情况。
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided Mechanism level: Failed to find any Kerberos TGT]
- 确保策略文件存在并且可由当前用户访问。cksum将文件与已知的工作副本进行比较,并在必要时进行替换:
$JAVA_HOME/jre/lib/security/US_export_policy.jar
$JAVA_HOME/jre/lib/security/local_policy.jar
- 确保为KDC和Principal设置了最大可再生寿命。请参阅知识文章, Impala服务无法以错误开头:“未能找到任何Kerberos tgt”
- 检查服务的配置,其中包含用户可以模拟其他用户的条目。通常列为proxyusers或类似配置。
- 升级到CDH 5.3。
注意:请参阅以下知识文章:
- HBase Canary测试无法更新导致HBase的Kerberos票证:SASL身份验证失败消息
- HiveServer2定期无法使用Sentry运行查询
- 通过Cloudera Manager为指定用户生成凭证。
- 以具有执行所需命令权限的用户身份运行kinit
- 更新JDK。请参阅《Cloudera Security:身份验证问题故障排除》
- 安装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)]
- 升级JDK:Cross Realm Authentication with Cluster Services Fail with GSS error (63) due to KRB/JDK 6 Bug
- 切换到TCP通过以下设置在krb5.conf中:udp_preference_limit = 1
- 确保存在krb5.conf的[domain_realm]节中的任一条目,以将请求的Principal的主机映射到Kerberos领域,或者确保[libdefaults]中的default_realm条目存在且与该Principal匹配
请参阅 《Cloudera Security:身份验证问题故障排除》
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 的版本也会增加,并且更新后的密钥必须同时部署到这两个服务并重新启动。
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Receive timed out)]
配置Kerberos客户端配置krb5.conf以使用TCP和/或调查网络问题。请参阅在与KDC通信时强制Kerberos客户端使用TCP
org.apache.hadoop.security.authentication.client.AuthenticationException: GSSException: Failure unspecified at GSS-API level (Mechanism level:Specified version of key is not available (44))
- 根据需要重新分配密钥,然后重新启动过程。
- 请参阅使用kinit和klist对Hadoop Kerberos问题进行故障排除
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的信息
从Cloudera Manager中,导航到 管理>安全性 ,然后单击 导入Kerberos帐户管理器凭据以将管理凭据重新导入到Cloudera Manager中。
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
确保主机名解析为与KDC和其他服务通信的服务的IP。查看:错误:访问Oozie WebUI时出现“ HTTP状态401”
至少升级到JDK8的51更新
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”异常
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
is not allowed to impersonate hdfs
检查请求的服务的配置中是否包含诸如hadoop.proxyuser.hdfs.*之类的条目,或查看以下文章以获取更多信息: 启用Kerberos的BDR HDFS复制失败,并显示“不允许模拟hdfs”异常
[外链图片转存中…(img-5vh0xOpG-1715711697274)]
[外链图片转存中…(img-QIGSnZxq-1715711697275)]
[外链图片转存中…(img-ND8IIQWF-1715711697275)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新