How does Kerberos work?

[#1]

I will elaborate the question How does Kerberos work? from this Question.

I am unable to understand how it is doing its functions. In my case, we enabled kerberos using existing Active directory(Automated installation) . Some of these questions might sound stupid, Please bear with me.

I will put all my understanding here, correct me if i am wrong.

• It Will use Active directory as KDC.
• As soon as the user login into the system, AS will generate TGT and TGS will issue a ticket with that TGT. (AS and TGS will lie in AD)
• It Will have to create principals and key tabs for all the service users,services, local users, AD users in this active directory.But it is only creating principals and keytabs for service users like hdfs,hive.
• The problem which we are facing is, it is not generating keytabs for local linux users, which is restricting them to use the services even thought they have access to those services(created policies in ranger).

Questions:

• How do we generate key tabs for local users and AD users(which is integrated with OS using SSSD)? should we integrate AD with ambari in order to gererate keytabs for AD users ?
• Is AD the KDC here ? Based on what AS will issue TGT ? is it after succesfull login and Keytab for that user ?

[#2]

@vinay kumar

Answering inline

• It Will use Active directory as KDC.

YES.That's Correct.

• . As soon as the user login into the system, AS will generate TGT and TGS will issue a ticket with that TGT. (AS and TGS will lie in AD).

When you do a kinit, Only TGT is obtained from the KDC. TGS will be obtained only when you run the actual command.

Say for example you run hadoop fs -ls /

You can use "klist" to check what tickets you hold.

• It Will have to create principals and key tabs for all the service users,services, local users, AD users in this active directory.But it is only creating principals and keytabs for service users like hdfs,hive.

Creating principals and keytabs should be done as part of Kerberising the cluster.

• The problem which we are facing is, it is not generating keytabs for local linux users, which is restricting them to use the services even thought they have access to those services(created policies in ranger).

AD comes with LDAP and KDC . So you would ideally want to maintain all users just in AD and sync them in Unix machines via SSSD/Windbind etc. You do not want to have local user as well as AD users . This is not at all recommended. If you want to create a keytab for the local user, then that user should be created in AD and then keytabs can be created on top of it.

Here is the very good github book about Kerberos. You may bookmark it

https://community.hortonworks.com/content/kbentry/1327/kerberos-the-missing-guide.html

Hope this helps.

[#3]

does the user has to manually run "kinit" command in order to get the ticket ?? let say, i have a hue interface where AD users can log in and fire the queries. If that is the case, how will he get the ticket ??

PS: we configured SSSD to authenticate the users in AD.

[#4]

For the Hue example, you have to create a Hue user in AD and then create a keytab file for Hue. This is where I am stuck. How do you create the keytab file for the Hue user?

[#5]

We're using a local KDC and have created service principals for the Hadoop service accounts (yarn, hdfs, mapred, etc..) The services startup and automatically generate their TGT's to access the Hadoop services.

Regular users authenticate against Active Directory using a cross-realm one way trust that has been setup.When those users login to Linux, they get a TGT from the local KDC with their AD credentials (e.g. bk835@ACME.ORG)

If you have multiple Hadoop clusters, you may run into collisions with the same Hadoop usernames existing in AD (e.g. yarn, hdfs, mapped, etc...). Because of this, I've convinced the customer to use separate KDC's for each Hadoop realm. I've got three clusters setup. Setting up a KDC on Linux is fairly straightforward and I can control it rather than depending on the AD administrators to do something for me with respect to issues with service principals or keytab files.

[#6]

@Bryan King

Regarding username conflict.Alternative approach could be customizing the username specific to the cluster(say for eg <cluster-name>-hdfs,<cluster-name>yarn ) and maintain all of them in single KDC.

[#7 · Accepted solution]

Here are some additional details to go with what @jramakrishnan posted:

It Will use Active directory as KDC.

If you enabled Kerberos specifying to use an Active Directory as the KDC, Ambari will configure the underlying Kerberos infrastructure (via the /etc/krb5.conf file) to use that Active Directory for authentication. This includes when a user manually executes kinit from the command line and when services either use kinit or some internal mechanism to authenticate.

There are options for not directly using the Active Directory for services while using the Active Directory for users, if that is desired.

As soon as the user login into the system, AS will generate TGT and TGS will issue a ticket with that TGT. (AS and TGS will lie in AD)

The Active Directory is both the AS (Authentication Service) and TGS (Ticket Granting Service) or it is also known as the KDC (Key Distribution Center)

When a user logs into a non-windows host, typically no automated routine it performed to authenticate with the KDC (or Active Directory or AS). This is outside my scope of knowledge (I hope to get some experience with this soon), but I believe there are facilities that do or can be configured to do this - SSSD, NSS, PAM. So if an automated facility is not installed than one must manually authenticate with the KDC using the kinit command line utility to set up their credential cache and get their TGT.

On a windows host, if a user logs into a machine connected to a domain, I believe that a TGT is granted immediately and is available to applications that know how to use it. For example, I assume that Internet Explorer know how to use it and will provide a Kerberos ticket if needed by web-based applications.

It Will have to create principals and key tabs for all the service users,services, local users, AD users in this active directory.But it is only creating principals and keytabs for service users like hdfs,hive.

Ambari will only create the principals and key tabs file for users and services it knows about. These are the internal users like the hdfs administrator (hdfs-xxxx) and the Ambari test user (ambari-qa-xxxx); and service users like hive (hive/_HOST), data node (dn/_HOST), and resource manager (rm/_HOST).

However, if only one KDC is in use (many can be used if configured properly), then all users who need access to the Kerberized services will need to be able to authenticate with that KDC and thus will need an account. "Local users" and "AD users" should be the same thing in this scenario since all users need to be in the Active Directory. Typically interactive users do not use keytab files. Since they are interactively authenticating they are able to provide their password. The keytab file is essentially a file containing a table of encrypted keys that the Kerberos infrastructure can be instructed to use when attempting to authenticate a user. This is useful in an non-interactive scenario, like when a service is requesting tickets from the KDC.

The problem which we are facing is, it is not generating keytabs for local linux users, which is restricting them to use the services even thought they have access to those services(created policies in ranger).

As mentioned above, "local users" and "AD users" are the same. So all users need to have accounts in the Active Directory so they can kinit (or authenticate) with it and set up their ticket cache and get their TGT. Also, interactive users should not get keytabs. They are for non-interactive facilities like the hadoop services. Interactive users should be forced to present their password when authenticating with the KDC (or Active Directory). This can happen either automatically, when logging in into the host (if the proper software is installed) or manually using kinit.

If you wanted to separate "local users" from "AD users", you can set up a local KDC (MIT KDC) and set a trust relationship between that KDC and the Active Directory. Then all of hadoop users and services, as well as the local users, can go into the MIT KDC, while the "AD users" remain separated in a clean Active Directory.

[#8]

Fantastic answer. In regards to SSSD please see this question regarding adding users from active directory. I have exactly the same set up as @vinay kumar where AD is my KDC.