Created on 06-04-2018 09:58 AM - edited 09-16-2022 06:17 AM
Hi Folks,
I have configured MIT kdc which is integrated with Active directory according to referred link:
https://community.hortonworks.com/articles/59635/one-way-trust-mit-kdc-to-active-directory.html
My question is:
1. How can i test one way trust is successfully created or not?
2. Users will persist on AD server and services will persist on hadoop cluster. Should i have to create user principal in kerberos database?
3. If yes, Should be have to add principal in kerberos manually whenever new user created in AD server?
Regards,
Vinay
Created 06-04-2018 02:58 PM
1. How can i test one way trust is successfully created or not?
> Try to access any kerberized services on your cluster with ticket from your AD. For example
kinit user@AD.REALM hdfs dfs -ls / # cluster is using mit kerberos in MIT.REAM wich is different thatn AD.REALM, only if one way trust is correctly configured the above will work
2. Users will persist on AD server and services will persist on hadoop cluster. Should i have to create user principal in kerberos database?
> No need to create user principals in kerberos database since you have them in AD
3. If yes, Should be have to add principal in kerberos manually whenever new user created in AD server?
> No, this will lead to duplicate users and will be very hard to maintain. Keep users in AD only.
HTH
*** If you found this answer addressed your question, please take a moment to login and click the "accept" link on the answer.
Created 06-04-2018 02:58 PM
1. How can i test one way trust is successfully created or not?
> Try to access any kerberized services on your cluster with ticket from your AD. For example
kinit user@AD.REALM hdfs dfs -ls / # cluster is using mit kerberos in MIT.REAM wich is different thatn AD.REALM, only if one way trust is correctly configured the above will work
2. Users will persist on AD server and services will persist on hadoop cluster. Should i have to create user principal in kerberos database?
> No need to create user principals in kerberos database since you have them in AD
3. If yes, Should be have to add principal in kerberos manually whenever new user created in AD server?
> No, this will lead to duplicate users and will be very hard to maintain. Keep users in AD only.
HTH
*** If you found this answer addressed your question, please take a moment to login and click the "accept" link on the answer.
Created 06-04-2018 05:28 PM
@Vinay K if one way trust is correctly configured user principals will be able to authenticate using user@AD.REALM. My understanding is now you are asking how then those UPN (user principals names) are going to be authorized by Hadoop services. For this you need to update the auth_to_local rules (in core-site.xml) and add rules for user@AD.REALM to map to user. Then you can set posix/authorization rules for this user (no longer UPN because it has been mapped using auth_to_local) using Ranger or regular hdfs posix permissions/service acl.
More here: https://community.hortonworks.com/articles/14463/auth-to-local-rules-syntax.html
Note: Please comment on this post rather than creating a new answer thanks!
Created 06-05-2018 09:11 AM
As i understand, My solution is hidden in "mapped using auth_to_local". I have to specify policy in HDFS configuration for provide services access to users based.
Correct me if i'm wrong.
Created 06-05-2018 12:04 PM
@Vinay K yes, you will need to add appropiate policies on Ranger to authorize users to resources.
Created 06-08-2018 05:02 AM
Thanks @Felix Albani
It's working.
Created 06-04-2018 05:05 PM
I agree with 2nd and 3rd answer.
If we use user@AD.REALM for access kerberized service on cluster, how we define service access to user@AD.REALM?
As i know, We don't need to create any service principal at AD server. Just we have to create trust with AD servers.
Can you please help me to understand the concept?
Regards,
Vinay
Created 06-04-2018 06:57 PM
In a one-way trust between a trusted domain (AD Domain) and a trusting domain (MIT KDC), users or computers in the trusted domain can access resources in the trusting domain. However, users in the trusting domain cannot access resources in the trusted domain.
So basically you tell your MIT KDC to trust the users in the AD to access resources in your cluster. Service access happens the same way as for MIT KDC users. Service will ask Kerberos to authenticate, if that user is authenticated to use that service, Kerberos will check the domain of the user and accordingly if that user is from a trusted domain, Kerberos will ask the AD/LDAP to authenticate and if AD authenticates, Kerberos trusts that user and so does your service.
Created 06-05-2018 09:13 AM