Adding user to Kerberised MIT KDC cluster

[#1]

I have setup my kerberised dev cluster.I now need to add 5 users to my cluster who can can access hdfs,hive,hbase,submit spark jobs.I have MIT KDC installed on one of the node.Any link or documentation will be helpful.TIA.

[#2]

Hi @Mudit Kumar ,

for adding your users you need to create principals for them in the Kerberos database.

e.g. connect to the node where MIT-KDC is running, then

sudo kadmin.local "addprinc <username>" 

#replace <username> by your real usernames

So that you are able to grab a valid Kerberos ticket for those 5 users. You can verify this by executing

kinit <username>

this should ask for the corresponding password of that user (!! the password you provided at creation time of the principal above !!), followed by

klist

After grabbing a Kerberos ticket you can start executing commands to the cluster, like "hdfs dfs -ls"

If you have enabled authorization as well, you have to add those new users to the ACLs appropriately.

[#3 · Accepted solution]

@Mudit Kumar

You have deployed and secured your multi-node-cluster with an MIT KDC running on a Linux box (dedicated or not), this can also be applied on a single node cluster.

Below is a step by step procedure

Assumption

• KDC is running
  
• KDC is created
  
• KDC user and master password is available
  
• REALM: DEV.COM
  
• Users : user1,user2,user3-user5
  
• Edge node: for users Kerberos
  
• Admin user is root or sudoer
  

A good solution security-wise is to copy the generated keytabs to the users'home directory. If these are local Unix users NOT Active directory then create the keytabs in e.g /tmp and later copy them to their respective home directories and make sure to change the correct permissions on the keytabs.

You will notice a node dedicated to users EDGE NODE, all client software are installed here and not on the data or name nodes!

Change directory to tmp

# cd /tmp 

With root access, no need for sudo, specify the password for user1

# sudo kadmin.local 
Authenticating as principal root/admin@DEV.COM with password. 
kadmin.local: addprinc user1@DEV.COM 
WARNING: no policy specified for user1@DEV.COM; defaulting to no policy 
Enter password for principal "user1@DEV.COM": 
Re-enter password for principal "user1@DEV.COM": 
Principal "user1@DEV.COM" created. 

Do the above step for for all the other users too

addprinc user2@DEV.COM 
addprinc user3@DEV.COM 
addprinc user4@DEV.COM 
addprinc user5@DEV.COM 

The keytabs with be generated in the current directory

Generate keytab for user1

The keytab will be generated in the current directory

# sudo ktutil 
ktutil: addent -password -p user1@DEV.COM -k 1 -e RC4-HMAC 
Password for user1@DEV.COM: 
ktutil: wkt user1.keytab 
ktutil: q 

You MUST repeat the above for all the 5 users

Copy the newly created keytab to the user's home directory, in this example I have copied the keytab to /etc/security/keytabs

# cp user1.keytab  /etc/security/keytabs

Change ownership & permission here user1 belongs to hadmin group

# chown user1:hadmin user1.keytab 

Again do the above for all the other users. A good technical and security best practice is to copy the keytabs from the kdc to edgenode respective home directories and change the ownership of the keytabs

Validate the principals in this example the keytabs are in /etc/security/keytabs

# klist -kt /etc/security/keytabs/user1.keytab 
Keytab name: FILE:/etc/security/keytabs/user1.keytab 
KVNO         Timestamp                   Principal 
-----------  ------------------- ------------------------------------------------------ 
1            05/10/2018 10:46:27         user1@DEV.COM 

To ensure successful ticket attribution the user should validate the principal see example below and use it grab a ticket , the principal will be concatenated with the keytab when running the kinit

# klist -kt /etc/security/keytabs/user1.keytab 
Keytab name: FILE:/etc/security/keytabs/user1.keytab
KVNO     Timestamp                 Principal
-------- ------------------------ --------------------------------------------------------
1        05/10/18 01:00:50        user1@DEV.COM
....    ..................        ..............
1        05/10/18 01:00:50        user1@DEV.COM

Test the new user1 should try grabbing a Kerberos ticket (keytab + principal)

# kinit -kt /etc/security/keytabs/user1.keytab  user1@DEV.COM 

The below command should show the validity of the Kerberos ticket

# klist 
Ticket cache: FILE:/tmp/krb5cc_0 
Default principal: user1@DEV.COM 
Valid starting             Expires               Service principal 
05/10/2018 10:53:48        05/11/2018 10:53:48   krbtgt/DEV.COM@DEV.COM 

You should be okay now access and successfully run jobs on the cluster