Support Questions

Find answers, ask questions, and share your expertise

How One-way Trust works - MIT KDC to Active Directory

avatar
Explorer

I read the article 

But I can't understand a few things

1. I have
a Hadoop (3.1.3)
MIT KDC cluster on a separate server
Active Directory for
server users with hadoop is not included in the domain

2. All hadoop NN, DN, JN, etc. services are launched using the keytabs created for them and are working successfully

3. any requests from the user from AD fall with an error

2024-01-27 15:56:07,949 DEBUG security.SaslRpcClient: Sending sasl message state: NEGOTIATE

2024-01-27 15:56:07,950 DEBUG security.SaslRpcClient: Get token info proto:interface org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolPB info:@org.apache.hadoop.security.token.TokenInfo(value=class org.apache.hadoop.hdfs.security.token.delegation.DelegationTokenSelector)
2024-01-27 15:56:07,951 DEBUG security.SaslRpcClient: tokens aren't supported for this protocol or user doesn't have one
2024-01-27 15:56:07,951 DEBUG security.SaslRpcClient: Get kerberos info proto:interface org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolPB info:@org.apache.hadoop.security.KerberosInfo(clientPrincipal=, serverPrincipal=dfs.namenode.kerberos.principal)
2024-01-27 15:56:07,953 DEBUG security.SaslRpcClient: RPC Server's Kerberos principal name for protocol=org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolPB is hdfs/hadoop01dev.local@HADOOP.LOCAL
2024-01-27 15:56:07,953 DEBUG security.SaslRpcClient: Creating SASL GSSAPI(KERBEROS) client to authenticate to service at hadoop01dev.local
2024-01-27 15:56:07,955 DEBUG security.SaslRpcClient: Use KERBEROS authentication for protocol ClientNamenodeProtocolPB
2024-01-27 15:56:07,987 DEBUG security.UserGroupInformation: PrivilegedActionException as:user1@AD.LOCAL (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Fail to create credential. (63) - No service creds)]

single-party trust between AD and MIT KDC is set up
I can't understand what algorithm works in this scheme for users in AD through kinit they get a ticket to AD, but how do they get into hadoop, which works with MIT KDC tickets?
It turns out that after authentication via kinit in AD, they should receive a ticket to MIT KDC somehow? or does this ticket get a NameNode for them , for example?
Can someone explain how this mechanism works?

 

1 ACCEPTED SOLUTION

avatar
Explorer

the problem was in trust - the password was incorrectly set in the MIT KDC when creating the trust

View solution in original post

4 REPLIES 4

avatar
Community Manager

@avs2211, Welcome to our community! To help you get the best possible answer, I have tagged in our HDFS experts @Asok @willx @mszurap @rki_  who may be able to assist you further.

Please feel free to provide any additional information or details about your query, and we hope that you will find a satisfactory solution to your question.



Regards,

Vidya Sargur,
Community Manager


Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.
Learn more about the Cloudera Community:

avatar
Explorer

traffic analysis shows an error

KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN

requests to dfs from a user in MIT KDC are successfully executed

Checking

./hdfs groups

returns the correct set of groups

but the AD user's requests after kinit return the above error

avatar
Explorer

the problem was in trust - the password was incorrectly set in the MIT KDC when creating the trust

avatar
New Contributor

The password is correct but the same problem occurs