Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

How does the client know which service ticket to request from the TGS?

avatar
Explorer

Hi,

I think I've got my head around most things in the client/server/kdc interactions for kerberos authentication, apart from one thing I can't quite see: When does the client request the service ticket from the TGS (extra for experts - which class/method in the client source?)? How does it know which service ticket to request?

I had a go at reading through the client code, even debugging and stepping through it on a kerberised sandbox. The closest I got to maybe seeing it was when the client started performing a SASL connection to the namenode from org.apache.hadoop.ipc.Client and into org.apache.hadoop.security.SaslRpcClient - it seemed like the client sent a negotiation request to the namenode, and the namenode sent back a response which is then unpacked in SaslRpcClient.getServerPrincipal(). This interaction seems to only be between the name node and the server though? Does the client itself not interact with the TGS, and the server does it on its behalf? But that would mean the client sends the server the users TGT, and kind of doesn't fit with most of the explanations of Kerberos that say the client itself uses the TGT to request a service ticket from the TGS...

Any help/info would be greatly appreciated - I guess I don't really need to know down to this level, but I tend to like to understand how stuff works.

Cheers,

Tom

1 ACCEPTED SOLUTION

avatar

@Tom Ellis, you mentioned finding the SaslRpcClient class. That's a very important piece. This is the class that handles SASL authentication for any client-server interaction that uses Hadoop's common RPC framework. The core Hadoop daemons in HDFS and YARN, such as NameNode and ResourceManager, make use of this RPC framework. Many other services throughout the Hadoop ecosystem also use this RPC framework.

Clients of those servers will use the SaslRpcClient class as the entry point for SASL negotiation. This is typically performed on connection establishment to a server, such as the first time a Hadoop process attempts an RPC to the NameNode or the ResourceManager. The exact service to use is negotiated between client and server at the beginning of the connection establishment, during the negotiation code that you mentioned finding. The service value will be different per Hadoop daemon, driven by the shortened principal name, e.g. "nn".

However, you won't find anything in the Hadoop source code that explicitly references the TGS. Instead, the Hadoop code delegates to the GSS API provided by the JDK for the low-level implementation of the Kerberos protocol, including handling of the TGS. If you're interested in digging into that, the code is visible in the OpenJDK project. Here is a link to the relevant Java package in the OpenJDK 7 tree:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/f51368baecd9/src/share/classes/sun/security/jgss/krb...

Some of the most relevant classes there would be Krb5InitCredential and Krb5Context.

View solution in original post

2 REPLIES 2

avatar
Explorer

I guess a further question would then be - how does the HBase Thrift Server do it when authenticating user principals?

avatar

@Tom Ellis, you mentioned finding the SaslRpcClient class. That's a very important piece. This is the class that handles SASL authentication for any client-server interaction that uses Hadoop's common RPC framework. The core Hadoop daemons in HDFS and YARN, such as NameNode and ResourceManager, make use of this RPC framework. Many other services throughout the Hadoop ecosystem also use this RPC framework.

Clients of those servers will use the SaslRpcClient class as the entry point for SASL negotiation. This is typically performed on connection establishment to a server, such as the first time a Hadoop process attempts an RPC to the NameNode or the ResourceManager. The exact service to use is negotiated between client and server at the beginning of the connection establishment, during the negotiation code that you mentioned finding. The service value will be different per Hadoop daemon, driven by the shortened principal name, e.g. "nn".

However, you won't find anything in the Hadoop source code that explicitly references the TGS. Instead, the Hadoop code delegates to the GSS API provided by the JDK for the low-level implementation of the Kerberos protocol, including handling of the TGS. If you're interested in digging into that, the code is visible in the OpenJDK project. Here is a link to the relevant Java package in the OpenJDK 7 tree:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/f51368baecd9/src/share/classes/sun/security/jgss/krb...

Some of the most relevant classes there would be Krb5InitCredential and Krb5Context.