Kerberos based authentication for Presto

[whu...@atlassian.com]

Hi all,

We are trying to enable Kerberos authentication for our Presto cluster (version 0.143) on Amazon EMR (version emr-4.6.0) based on this guide:

http://teradata.github.io/presto/docs/current/security/server.html#kerberos-principals-and-keytab-files

(The guide is from Teradata, but the corresponding code seems to have been merged back into core Presto already. There is also a recent PR [1] to pull this documentation into the presto repo.)

So far, we successfully managed to:
(1) set a static hostname for the Presto coordinator node (MASTER node in EMR cluster)
(2) update the DNS configuration to enable lookup of our internal KDC server (which is accessible from the Presto master node)
(3) bind the Presto coordinator to a Windows domain, by running the "domainjoin-cli" command (provided by PBIS Open) on the coordinator node.

However, at this point we are stuck. If our presto coordinator node is joined to our Windows domain (see step (3) above), how do we configure Kerberos auth for Presto? In particular, we are struggling to understand the following questions:

(A) As we understand it, the following steps in the guide are to create 1) a computer principal "presto/presto-coordina...@EXAMPLE.COM" for the machine on which the coordinator is executing, and 2) a user principal "pre...@EXAMPLE.COM" for the user account under which the Presto server is executing on that machine. Are both accounts strictly required, or would it be sufficient to create the computer principal only? What are the roles and responsibilities of both principals?

kadmin
> addprinc -randkey pre...@EXAMPLE.COM
> addprinc -randkey presto/presto-coordina...@EXAMPLE.COM

(B) Do we need to run the Presto server (i.e., the com.facebook.presto.server.PrestoServer Java process) under a Domain Account user? In Amazon EMR, by default, Presto runs as local user "presto" - can we continue to run the process under the local "presto" user, or does it somehow have to run under a Domain Account user (i.e, the user principal created in (A))?

(C) Where should the Service Principal Name (SPN) [2] be registered, on the machine account or on the user account?

If anyone has managed to successfully run Presto with Kerberos auth, we would highly appreciate if you could point us in the right direction to help in getting this set up.

Many thanks,
Waldemar

[1] https://github.com/prestodb/presto/pull/5217
[2] https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx

[Wallin, Christina A]

Hi Waldemar,

With the caveat that we have only run Kerberos when connecting to a Linux-based KDC, here it goes.

First question: what is your setup exactly? From your step (3), it seems like you're connecting to Windows Active Directory via Kerberos. The instructions in the documentation don't apply to AD, but I found a super helpful link about how to set up Kerberos with AD for another product [1], most of which should apply to Presto as well.

To give a general overview of how authenticating to the Presto server via Kerberos should work, you need to:
1. Create a service principal for the Presto server -- I believe in the AD world, this translates to setting up the service principal name. For Presto, it can be called presto/presto-coordinator.example.com (though for the JDBC/ODBC drivers, it must be called HTTP/presto-coordinator.example.com). The presto@REALM principal is not necessary.
2. Export the keytab file for that service principal and copy it from the AD to the Presto server
3. Ensure that your /etc/krb5.conf file is set up properly, and that you can kinit with the keytab you made.
4. Set up SSL for Presto [2]
5. Set the Presto Kerberos configs appropriately [3]
6. Restart Presto to pick up the changes, then connect to Presto via any user principal. It's easiest to debug if you start out with the CLI first [4], but after that's working, you can try connecting via the JDBC/ODBC driver available from the Teradata website [5].

You might need to fiddle with the encryption types; Java has a restricted set of cryptographic keys installed by default (unless you install the JCE [6]), and I'd imagine that there are some restrictions on the AD side.

To answer your the direct question of yours that's still relevant:

(B) Do we need to run the Presto server (i.e., the com.facebook.presto.server.PrestoServer Java process) under a Domain Account user? In Amazon EMR, by default, Presto runs as local user "presto" - can we continue to run the process under the local "presto" user, or does it somehow have to run under a Domain Account user (i.e, the user principal created in (A))?

I don't know if running the "domainjoin-cli"command causes additional constraints, but other than that, this should not matter. I'm also not sure that domainjoin-cli is necessary.

Hope this helps. Keep us posted with how you get this working or any other challenges along the way!

Christina

[1] https://www.safesquid.com/content-filtering/integrating-linux-host-windows-ad-kerberos-sso-authentication
[2] http://teradata.github.io/presto/docs/current/security/server.html#server-java-keystore
[3] http://teradata.github.io/presto/docs/current/security/server.html#presto-coordinator-node-configuration
[4] http://teradata.github.io/presto/docs/current/security/cli.html
[5] http://www.teradata.com/products-and-services/presto-download/
[6] http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

[Jothikumar]

Hi Christina,

I am following the same documentation from Teradata to set kerberos authentication for a EMR- Presto cluster. Right now just testing with a single node presto server.

Create a service principal for the Presto server -- I believe in the AD world, this translates to setting up the service principal name. For Presto, it can be called presto/presto-coordinator.example.com (though for the JDBC/ODBC drivers, it must be called HTTP/presto-coordinator.example.com). The presto@REALM principal is not necessary.

I created the following

the service principal name is presto/<fqn or private ip address of the master node>@REALM. Since the presto-coordinator.example.com is just for example

Added these in config.properties

http.server.authentication.enabled=true
http.server.authentication.krb5.service-name=presto/<fqn or private ip address of the master node>
http.server.authentication.krb5.keytab=/etc/presto/conf/presto.keytab
http.authentication.krb5.config=/etc/krb5.conf
http-server.https.enabled=true
http-server.https.port=8888
http-server.https.keystore.path=/etc/presto/conf/keystore.jks
http-server.https.keystore.key=password

Setup SSL and keystone as per the documentation

Executing presto cli

export JAVA8_HOME=/usr/lib/jvm/java-1.8.0
PRESTO_HOME=/usr/lib/presto
export PATH=$JAVA8_HOME/bin:$PATH
$PRESTO_HOME/bin/presto-cli-0.143-executable \
--server https://ip-<ip address>.ec2.internal:8888 \
--enable-authentication \
--krb5-config-path /etc/krb5.conf \
--krb5-principal user@REALM \
--krb5-keytab-path ./presto.keytab \
--krb5-remote-service-name presto/<fqn or private ip address of the master node>\
--keystore-path ./keystore.jks \
--keystore-password password \
--catalog hive

But i get a

"Error running command: javax.net.ssl.SSLHandshakeException: General SSLEngine problem"

Can't proceed further. Any suggestion

Thanks
Jothikumar

[Wallin, Christina A]

Hi Jothikumar,

Your error is with how you have SSL set up (that's why you have "Error running command: javax.net.ssl.SSLHandshakeException: General SSLEngine problem"). Make sure that
1. You have ip-<ip address>.ec2.internal added to keystore.jks
2. keystore.jks is accessible by the presto user (or whatever user Presto is running as)

However, you are going to soon have a Kerberos issue, once you get SSL working:

http.server.authentication.krb5.service-name should be JUST presto, it shouldn't have the host. Same with the --krb5-remote-service-name argument for the CLI.

While you're double checking things, make sure that the Kerberos keytab for the server (presto.keytab) is accessible by the Presto user.

And finally, in the CLI command, the keytab given must match the krb5 principal given. Unless presto.keytab has both the credentials for presto and user, the following is probably wrong:
--krb5-principal user@REALM \
--krb5-keytab-path ./presto.keytab \

I recommend adding extra debug output when running the CLI: http://teradata.github.io/presto/docs/current/security/server.html#additional-kerberos-debugging-info.

Christina
________________________________________
From: Jothikumar [kbmk...@gmail.com]
Sent: Friday, May 20, 2016 1:21 PM
To: Presto
Cc: Wallin, Christina A
Subject: Re: Kerberos based authentication for Presto

[Jothikumar]

Thanks Christina,

I think i might have made a mistake while creating the keystore

keytool -genkeypair -alias presto -keyalg RSA -keystore keystore.jks

Instead of saying "presto" , i actually need to give the principal name here

my principal name which is presto/<fqn or private ip address of the master node>@REALM. This is the principal for the presto service i created in the KDC.

Also when giving the first name in the keystore i should give the unqualified hostname (ip address) of the presto co ordinator. I am using the same keystore for both the coordinator and cli and it is accessible by the co-ordinator and the cli. The coordinator (presto server) is run by "presto" user and the cli is executed by hadoop user. Both have access to the keystore.

I have a slight confusion from the documentation, it says

http.server.authentication.krb5.service-name = The Kerberos server name for the Presto coordinator. Must match the Kerberos principal

Then why it is just presto , my principal is presto/<fqn or private ip address of the master node>@REALM

Please let me know my understanding is correct, I will test it and update

Thanks
Jothikumar

[Wallin, Christina A]

Hi Jothikumar,

The keystore has nothing to do with Kerberos; it's to set up HTTPS on the Presto server so that the connection is secure. The alias you use doesn't matter; it just serves as an identifier for which certificate it is. The thing that matters is that for the field "What is your first and last name", you give the FQDN of the Presto coordinator. It's significantly easier to use a FQDN and not an IP address, but if you're going to use an IP address, you can do something like this:

keytool -genkeypair -alias presto -keyalg RSA -keystore {keystore_path} -keypass {keystore_password} -storepass {keystore_password} -dname "CN={master_fqdn}, OU=, O=, L=, S=, C=" -ext san=ip:{ip}

Note that the above command doesn't prompt you for input. You can substitute either the coordinator FQDN or the ip instead of {master_fqdn}, namely the CN (aka Common Name). See here for more information: http://stackoverflow.com/questions/8443081/how-are-ssl-certificate-server-names-resolved-can-i-add-alternative-names-using/8444863#8444863.

The docs might have been a little unclear on the point about http.server.authentication.krb5.service-name, but it definitely should not be qualified by the hostname.

Happy Kerberizing!

Christina
________________________________________
From: Jothikumar [kbmk...@gmail.com]

Sent: Friday, May 20, 2016 2:05 PM

[Eric Diven]

Hi Jothikumar,

I'm glad you're finding the docs useful, and I apologize for the confusion.

I believe the answer to your question about http.server.authentication.krb5.service-name has two parts:
1) It's probably OK to omit the realm because I set up the defaultRealm in /etc/krb5.conf. If you want to try it both ways and let me know what you find, I can clarify the docs. You're also welcome to submit a pull request.
2) The hostname/fqdn portion is probably omitted because either presto or jetty adds it in at some point. I'm only reasonably certain this happens for the server side. I *do* know that it happens on the cli side of things. If you take a look at the cli.sh script on the cli documentation[0], you'll see the line

  --krb5-remote-service-name presto
If you qualify the servicename there, you'll get errors authenticating presto/server.example.com/server.ex...@EXAMPLE.COM.

Again, we'll be happy to take pull requests on the docs. Or, if you'd rather just close the loop here, we'll update the docs ourselves.

Eric

[Jothikumar]

Hi Eric / Christina,

Thanks for the detailed explanation, It is making a lot of sense now. I am able to setup kerberos successfully between the Presto - coordinator (Single node EMR) and the presto - cli.

I made the mistake of giving the wrong name in the CN part of keystore, where Christina explained in detail and i was able to fix it and make progress.

Now comes the part where i want to connect the kerberized coordinator with a JDBC complaint sql client and ODBC as well. From the previous discuss there was a mention that the principal name is HTTP/FQDN@REALM.

What about the java keystore in case of JDBC or ODBC. Appreciate it, if you have any steps for JDBC connection to the presto coordinator.

Thanks for all your help
Jothikumar

[Jothikumar]

HI All,

I see the steps like this

in the /etc/presto/config.properties file, set the following properties:

http.server.authentication.krb5.service-name=HTTP
http.server.authentication.krb5.keytab=HTTP.keytab

On your client machine, in the java.policy file for your Java environment, include the following line:
permission java.util.PropertyPermission "javax.security.auth.useSubjectCredsOnly", "write";

Connect to the Presto server using a connection URL written in the following format:
jdbc:presto://[Host]:[Port];enableKerberos=true;SSLCertificate=[SSLCert]

The variables are defined as follows:
[Host] is the DNS or IP address of the server.
[Port] is the number of the TCP port to connect to.
[SSLCert] is the full path to a .jks file that contains the SSL certificate for the server.

Reference doc : http://www.simba.com/products/Presto/doc/v1/JDBC_InstallGuide/content/jdbc/pr/authenticating/kerberos.htm

I am going to try this and will update, If you see any problems with this approach let me know.

Thanks
Jothikumar

[Jothikumar]

Doesn't work. Not sure what is the correct JDBC URL for connecting to Presto

Connection connection = DriverManager.getConnection("jdbc:presto://ip-<ipaddress>.ec2.internal:8888/hive/schema_name;enableKerberos=true;SSLCertificate=/home/hadoop/presto_keystore.jks","test",null);

If i use the teradata driver i get the below error

xception in thread "main" java.sql.SQLException: [Teradata][Presto](100073) Error fetching JSON content: No content to map due to end-of-input
at [Source: ; line: 1, column: 1].
at com.teradata.presto.client.PRClientUtil.toJsonNode(Unknown Source)
at com.teradata.presto.client.PrestoAPI.execute(Unknown Source)
at com.teradata.presto.dataengine.PRResultSet.execute(Unknown Source)
at com.teradata.presto.dataengine.PRQueryExecutor.execute(Unknown Source)
at com.teradata.presto.dataengine.metadata.PRQueryMetadataSource.executeQuery(Unknown Source)
at com.teradata.presto.dataengine.metadata.PRTablesMetadataSource.<init>(Unknown Source)
at com.teradata.presto.dataengine.PRDataEngine.makeNewMetadataSource(Unknown Source)
at com.teradata.dsi.dataengine.impl.DSIDataEngine.makeNewMetadataResult(Unknown Source)
at com.teradata.dsi.dataengine.impl.DSIDataEngine.makeNewMetadataResult(Unknown Source)
at com.teradata.presto.core.PRConnection.doConnectionTest(Unknown Source)
at com.teradata.presto.core.PRConnection.connect(Unknown Source)
at com.teradata.jdbc.common.BaseConnectionFactory.doConnect(Unknown Source)
at com.teradata.jdbc.common.AbstractDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
Caused by: com.teradata.support.exceptions.GeneralException: [Teradata][Presto](100073) Error fetching JSON content: No content to map due to end-of-input
at [Source: ; line: 1, column: 1].
... 15 more

If i use the Open source presto jdbc driver, it doesn't even recognize the additional kerberos parameters.

Any help appreciated

Thanks
Jothikumar

[Eric Diven]

Hi Jothikumar,

The open source presto jdbc driver doesn't support Kerberos yet. For the moment the Teradata drivers are the only option.

Just so I'm clear, you were able to get the cli talking to the server, right? The CLI is probably easier to troubleshoot than the drivers.

If you have the CLI working, the next thing I would do is to watch the presto server logs while you're trying to connect with the driver. I think that the presto server returns an empty body when it returns an HTTP error code in the header, and that sounds like what you might be hitting.

You might try verifying that you have a ticket on the client machine by running klist.

In the meantime, I'll see if I can find somebody with more experience with the driver to weigh in.

Eric

Thanks
Jothikumar

--
You received this message because you are subscribed to the Google Groups "Presto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to presto-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Rickman]

Hi Jothikumar,

I work with Christina and Eric at Teradata...

You need to add "User=<kerberos principal name>" to the JDBC URL.  This will be the same value as you gave for "--krb5-principal" in the CLI.

jdbc:presto://ip-<ipaddress>.ec2.internal:8888/hive/schema_name;enableKerberos=true;SSLCertificate=/home/hadoop/presto_keystore.jks;User=<kerberos principal name>

Also, make sure you have a valid ticket on the client machine for the specified user before you try to connect.

[Jothikumar]

Hi Brian,

Thanks for the details.

I got the presto cli working (kerberized) by following the below documentation

http://teradata.github.io/presto/docs/current/security/server.html

For JDBC, as per the Teradata JDBCPrestoInstallGuide.pdf it says to add the below properties

/etc/presto/config.properties file, set the following properties:
http.server.authentication.krb5.service-name=HTTP
http.server.authentication.krb5.keytab=HTTP.keytab

This is different from the cli settings,

In CLI we add the below property

http.server.authentication.krb5.service-name=presto, We create a principal presto/{FQDN}@REALM and export it into a keytab

So for JDBC we need to create a principal with HTTP/{FQDN}@REALM and export it in a key tab and use that? So if i want both cli and JDBC working together in kerberos how the below property should be set

http.server.authentication.krb5.service-name=HTTP / Presto ?

Thanks
Jothikumar

[Eric Diven]

Hi Jothikumar,

If you're going to use the Teradata JDBC driver, you need to name the server principal HTTP, not presto. This is a limitation of the driver.

When you connect to the coordinator using the CLI, you need to specify --krb5-remote-service-name HTTP.

Neither the CLI nor the driver needs a keytab file for HTTP. Only the server needs a keytab file for HTTP.

The CLI and/or driver need a keytab file for the principal they're trying to authenticate as.

Eric

Thanks
Jothikumar

[kbmk...@gmail.com]

Hi All,

Thanks for all your support, JDBC access works fine with the Teradata driver.

Thanks
Jothikumar

[Eric Diven]

Awesome! Thanks for sticking with it.

What can we do to improve the documentation for the next person setting this up?

Thanks,

Eric

[kbmk...@gmail.com]

Hi Eric,

I got confused while creating the CN name for the java keystore and TLS. The CN name should match with the name we use to access the presto coordinator. If it is IP, then we need IP in the certificate

presto_host_name should match the CN name in the certificate

--server https://presto_host_name:<port> \

keytool -genkeypair -alias presto -keyalg RSA -keystore presto_keystore.jks -keypass password123 -storepass password123 -dname "CN=<presto_host_name>, OU=, O=, L=, S=, C=" -ext san=ip:<presto host ip>

The above command helped me.

Thanks
Jothikumar

[Eric Diven]

I'll make the CN requirements more explicit and update the pull request against mainline presto.

Thanks for the feedback!

Eric

Thanks
Jothikumar

[h...@atlassian.com]

Hi people,

We are setting up authentication for our presto cluster, we've got it working for the server and cli. But having some problems with the JDBC set up.

config.properties

http.server.authentication.enabled=true
http.server.authentication.krb5.service-name=HTTP
http.server.authentication.krb5.keytab=/etc/presto/presto.keytab
http.authentication.krb5.config=/etc/krb5.conf
http-server.https.enabled=true
http-server.https.port=7778
http-server.https.keystore.path=/etc/presto/presto.jks
http-server.https.keystore.key=<password>

CLI

java -Dsun.security.krb5.debug=true -jar /Users/hye/Downloads/presto-cli-0.147-executable.jar --debug --server https://socrates-auth-dev.data.internal.atlassian.com:7778 --enable-authentication --krb5-config-path /Users/hye/Downloads/krb5.conf --krb5-principal hye@<REALM> --krb5-keytab-path /Users/hye/Downloads/hye.keytab --krb5-remote-service-name HTTP --catalog hive --schema default --keystore-path=/Users/hye/Downloads/presto.jks --keystore-password=<password>

With debug on, we can see the successful exchange of tokens in the server and cli logs.

When we tried with JDBC however...

JDBC connection string

jdbc:presto://socrates-auth-dev.data.internal.atlassian.com:7778/hive/default;User=hye@<REALM>;enableKerberos=true;TimeZoneID=UTC;SSLCertificate=/Users/hye/Downloads/presto.jks;LogLevel=6 

We get this error

[Teradata][Presto](100073) Error fetching JSON content: No content to map due to end-of-input
at [Source: ; line: 1, column: 1]. 

The connection never hits the server unlike the CLI connection. Looking at the debug logs in the JDBC.

2016-07-13 16:35:00.392 FINE   251 [pool-4-thread-39 - Q.flush] Jul 13 06:35:00.392 TRACE 39045 com.teradata.presto.client.PrestoAPI.execute("SELECT * FROM "system"."information_schema"."tables" WHERE table_schema LIKE '' AND table_name LIKE 'default'"): +++++ enter +++++
2016-07-13 16:35:00.392 FINE   251 [pool-4-thread-39 - Q.flush] Jul 13 06:35:00.392 TRACE 39045 com.teradata.presto.client.PRClientUtil.POST("SELECT * FROM "system"."information_schema"."tables" WHERE table_schema LIKE '' AND table_name LIKE 'default'"): +++++ enter +++++
2016-07-13 16:35:01.749 FINE   251 [pool-4-thread-39 - Q.flush] Jul 13 06:35:01.749 TRACE 39045 com.teradata.presto.client.PRClientUtil.POST("Error Detected during POST operation"): +++++ enter +++++

This doesn't really say what's wrong, is there somewhere else we can try looking to see where the problem is?

We already set up the server principal to be HTTP in line with the Teradata docs.

Thanks,

Hao

 

[Wallin, Christina A]

Hi Hao,

Usually if you get that error, it's an issue with SSL (the error message isn't propagated very well, but if it were, it would say something about not being able to authenticate). A few quick steps for debugging:

* Can you run queries from the CLI from the tpch connector? The Kerberos token exchange happens as the CLI is starting, but you don't know if SSL is set up right until you run queries.
* Are the permission for the keytab on the Presto server side set such that Presto can read it?
* Is the keytab the same on both the Presto side and the client side?
* Does your SSL certificate have socrates-auth-dev.data.internal.atlassian.com as the common name and not an IP?

Christina

---

From: presto...@googlegroups.com [presto...@googlegroups.com] on behalf of h...@atlassian.com [h...@atlassian.com]
Sent: Wednesday, July 13, 2016 3:56 AM
To: Presto
Cc: whu...@atlassian.com

Subject: Re: Kerberos based authentication for Presto

--

[Dain Sundstrom]

Getting all of the Keveros+SSL working in a real production is pretty challenging. What do you think about building a standalone tool for diagnosing these kinds of Kerberos setup issues?

-dain

> On Jul 13, 2016, at 6:44 AM, Wallin, Christina A <Christin...@Teradata.com> wrote:
>
> Hi Hao,
>
> Usually if you get that error, it's an issue with SSL (the error message isn't propagated very well, but if it were, it would say something about not being able to authenticate). A few quick steps for debugging:
>
> * Can you run queries from the CLI from the tpch connector? The Kerberos token exchange happens as the CLI is starting, but you don't know if SSL is set up right until you run queries.
> * Are the permission for the keytab on the Presto server side set such that Presto can read it?
> * Is the keytab the same on both the Presto side and the client side?
> * Does your SSL certificate have socrates-auth-dev.data.internal.atlassian.com as the common name and not an IP?
>
> Christina

[h...@atlassian.com]

Hi Christina,

1. We've actually ran queries through the hive connector and got it working in CLI. Just tried the TPCH connector and works too

2016-07-14T01:25:26.699Z INFO http-worker-153 stdout >>> KrbApReq: authenticate succeed.
2016-07-14T01:25:26.699Z INFO http-worker-153 stdout Krb5Context setting peerSeqNumber to: 204003340
2016-07-14T01:25:26.699Z INFO http-worker-153 stdout >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
2016-07-14T01:25:26.700Z INFO http-worker-153 stdout Krb5Context setting mySeqNumber to: 315418662
2016-07-14T01:25:26.700Z INFO http-worker-153 stdout >>> Constrained deleg from GSSCaller{UNKNOWN}
2016-07-14T01:25:26.724Z INFO query-execution-3 com.facebook.presto.event.query.QueryMonitor TIMELINE: Query 20160714_012525_00002_8pg7g :: Transaction:[63614139-2f6a-49e1-9fc4-4d7c12cfc972] :: elapsed 849.00ms :: planning 9.24ms :: scheduling 23.00ms :: running 48.00ms :: finishing 769.00ms :: begin 2016-07-14T01:25:25.861Z :: end 2016-07-14T01:25:26.710Z

2. The permissions should be ok since the auth works for the CLI.

3. Keytab on the server side is for the server principal 'HTTP/presto-auth.data.internal.atlassian.com@<REALM>'. The CLI uses my credentials that I've put into a keytab. The JDBC connection is meant to use the kerberos token on my machine (which I can see using klist).

4. The SSL cert is for *.data.internal.atlassian.com. I've tested the JDBC connection with authentication off but SSL turned on and it was working.

I am going to do some more testing and see if I can figure this out.

Thanks,

Hao

[h...@atlassian.com]

I got this working. Tried the JDBC driver via a java class and the error was a lot more useful.

Jul 14, 2016 4:56:16 PM org.apache.http.impl.auth.HttpAuthenticator generateAuthResponse
WARNING: NEGOTIATE authentication error: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm)
Exception in thread "main" java.sql.SQLException: [Teradata][Presto](100073) Error fetching JSON content: No content to map due to end-of-input

 at [Source: ; line: 1, column: 1].

The issue was the /etc/krb5.conf need to exist in that location. CLI has a variable to pass it through. MacOS doesn't default the config file to be at that location, creating the file there solved the issue.

Thanks =)