RStudio Server Pro (RSP) using RJDBC, Kerberos and HANA

Posit Professional & Hosted Products
1

We are using RSP on RHEL 7.5 and looking to authenticate with SAP HANA using Kerberos. The HANA server in configured for Kerberos and we have tested it using another windows server and it authenticated. We are using RJDBC to connect from RSP to HANA and must use a UID and Password in the connection string - dbConnect( drv,"jdbc:sap://xxxx.com:xxx", "UID", "password"). We would like it to authenticate without the UID and Password.

2

Very interesting! Do you have Kerberos set up for RSP, so that a user immediately gets a kerberos ticket issued upon login? This is done by integrating the PAM profile with Kerberos, and is definitely the preferable way to get things working. Documentation is here: http://docs.rstudio.com/ide/server-pro/r-sessions.html#kerberos

The next step is getting the RJDBC connection to utilize the Kerberos ticket once available. This can be done in parallel with the above, so long as the user doing the connection can execute kinit on the server and have a ticket issued.

Once the ticket is available, connecting using the ticket is a matter of a driver feature and driver configuration parameters. Unfortunately, this is different for all databases / drivers. Some will have you select a particular AuthMech, others will require Trusted_Connection=1, etc. If you can link to the documentation for the specific driver/version you are using, that would be helpful to determining if it supports a Kerberos-authentication connection and what the syntax is for engaging it. If it was provided by the vendor (SAP), they would also be a great resource to answer those questions too!

1 Like
3

Cole

Thank you for the response. We are actually okay with the RSP User Kerberos ticket being generated. We are able to run kinit and klist to see ticket for RSP:

[username@linuxhost /]$ kinit
Password for username@COMPANY.COM:
[username@linuxhost /]$ klist
Ticket cache: FILE:/tmp/krb5cc_40293
Default principal: username@COMPANY.COM

Valid starting       Expires              Service principal
09/27/2018 10:57:02  09/27/2018 20:57:02  krbtgt/COMPANY.COM@COMPANY.COM
        renew until 10/04/2018 10:56:25

We believe the issue is the correct ODBC or JDBC connection details for HANA. Here is the string we tried and the error received:

odbcconn <- odbcConnect("HD2")

For ODBC we are using these details (odbc.ini):

AuthMech=1
KrbFQDN=hana.company.com
KrbRealm=COMPANY.COM
KrbServiceName=krbtgt/COMPANY.COM@COMPANY.COM

This is the error/message we are receiving:

Warning messages:
1: In RODBC::odbcDriverConnect("DSN=HD2") :
  [RODBC] ERROR: state 08S01, code -10709, message [unixODBC][SAP AG][LIBODBCHDB SO][HDBODBC] Communication link failure;-10709 Connection failed (RTE:[200106] Protocol error, invalid authentication packet (m_server_at_my_company.com:30050))
2: In RODBC::odbcDriverConnect("DSN=HD2") : ODBC connection failed

If we use the UID and Password in the connection shown above we are able to access HANA:

> odbcconn <- odbcConnect("HD2",uid="user",pwd="xxxx")

Any help on connection details is appreciated for ODBC or JDBC.

4

Very interesting! Do you have access to the documentation for the ODBC driver that you are using? Does the driver / HANA support Kerberos authentication?

This error makes it look like one or the other (the driver, or the database) is breaking on the Kerberos protocol. I am unfamiliar with HANA, so I unfortunately do not have any direct / practical advice. However, some general debugging assistance:

  • Usually there is a way to ratchet up the logging verbosity for the driver (LogLevel=6 or something in the driver configuration). This would be in the driver documentation
  • If the odbc / jdbc driver supports Kerberos authentication, it should also implement additional logging verbosity on the Kerberos connection handshake. The way to enable this is to set the environment variable KRB5TRACE=/tmp/myfile.log This will enable additional logging from the client-side to the /tmp/myfile.log file.
  • The KDC and the database itself are another place that you can check logs to see what is happening on the server side and why the error is being thrown
  • If you use isql -v mydsn from the command line, you can get some additional verbosity and take R out of the picture. This can be helpful to do a pure test of the driver / connection ability

Also, this should be irrelevant, but the odbc package is newer than RODBC and has some improved performance, if you want to check it out!