How to pass authentication credentials to a database using Kerberos



This article describes how to configure RStudio Server Pro and Shiny Server Pro so that authenticated users can access databases without having to authenticate again. These instructions are useful if you want to:

  • Authenticate into RStudio Server Pro and query a database with the same login credentials
  • Access a Shiny Server Pro app that requires authentication and a live database connection.

In these instructions, we assume you are using Lightweight Database Access Protocol (LDAP), Active Directory (AD), and Red Hat Enterprise Linux (RHEL). We also explain how to configure the System Security Services Daemon (SSSD) and the Kerberos authenticating protocol.

Kerberos tickets facilitate the connection between server authentication and database authentication. You can configure RStudio Server Pro and Shiny Server Pro to generate a Kerberos ticket upon login that will be recognized by your database.


Shiny Server Pro provides an LDAP authentication method (or Active Directory) in which the server is configured to directly communicate with the LDAP/AD server. This topic is covered in the Shiny Server Admin Guide and a few support articles.

Shiny Server Pro also provides a method of generating Kerberos tickets for cases that the user credentials need to be passed to other applications such as a database. This is normally done through PAM, and is also covered in the Shiny Server Admin Guide

For a scenario that user authentication is against LDAP/AD server, but the credentials should be passed to other applications such as a SQL Server (a case which requires Kerberos ticket), we need a different way of configuring the system. That is what we will cover in this article.

There are multiple ways this can be achieved, but we just cover one specific case of using PAM, Kerberos, and sssd on the server that runs Shiny Server Pro. 


Configuring sssd

The following document describes in good detail how to configure a RedHat server with sssd for authentication against LDAP or Active Directory:

The sssd.conf file listed in the above document could be used as your configuration file after adjusting the parameter values according to your environment. Make sure all LDAP and krb5 parameters are set correctly according to the structure and properties of your LDAP server and krb5 domain(s).


Configuring Kerberos

pam_krb5 module is used for integration between PAM and Kerberos. Here is a sample of the configuration file /etc/krb5.conf that should be modified for your environment.


  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

  dns_lookup_realm = false
  ticket_lifetime = 24h
  renew_lifetime = 7d
  forwardable = true
  rdns = false
  default_realm = TEST.COM
  default_ccache_name = KEYRING:persistent:%{uid}

  TEST.COM = {
    kdc =
    admin_server =

[domain_realm] = TEST.COM = TEST.COM

# ignore_k5login = true : Never look for a .k5login file in the user's home directory. Instead, only check that the Kerberos principal maps to the local account name.
pam = {
  TEST.COM = {
    ignore_k5login = true


Configuring Shiny Server Pro

Shiny Server Pro needs to be configured for authentication through PAM and Kerberos, exactly as described in this section of the Admin Guide.


Testing Shiny Server Pro login

After making changes to the configuration files, following the instructions in the sssd document listed above, restarting all related services, bring up a Shiny application and login as a valid LDAP user. In all likelihood, this will be successful and you are done.



1- If login to Shiny Server Pro shows an error indicating invalid username/password, (and if you have entered correct credentials), this is most likely due to a configuration mismatch:

  • Double-check all parameters, specificially the LDAP host info.
  • Check the system log file (/var/log/messages or /var/log/syslog depending on the Linux flavor) for any related errors
  • Check the /var/log/secure file for the steps taken during authentication and whether or not all steps were successful. Usually you can see clear indications if there is a problem with krb5 (for example service is not running), or bad credentials.


2- If login to Shiny Server Pro does not show any error, but brings back the login page:

  • Check the /var/log/secure file. If this shows that authentication has been successful, , then the problem could be due to a known issue with number of groups a user belongs to. Shiny Server Pro fails to successfully log the user in if the list of groups exceeds 3k characters.

You can check the list of groups for a user using one of the following:

  • groups <username>
  • getent group | grep <username>


Workaround for the group issue:

As of this writing if you run into a login issue for users who belong to many groups, the workaround is to limit the number of groups being returned from LDAP/AD server, using group filters.

You already have a ldap_group_search_base parameter in the sssd.conf file. You can add a filter to this parameter using the following format:

ldap_group_search_base = ou=Groups,dc=test-ldap?subtree?(cn=*matching_string*)


For more info on specifying a filter refer to the following document:    (specially section on ldap_search_base)

For any change in the sssd.conf file to take effect you need to run the following commands:

sudo sss_cache -E
sudo service sssd restart 


Configuring RStudio Server Pro:

RStudio Server Pro needs to be configured for authentication through PAM and Kerberos, exactly as described in the Admin Guide section on Kerberos, with one change. Since authentication is done through LDAP, the users are not local users on the Linux server where RStudio Server Pro is running, and they do not have home directories. You need to use (or similar PAM modules) in your RStudio PAM profile so that when a user logs in for the first time, a home directory is automatically created.

Your /etc/pam.d/rstudio-session file will look something like the following:

auth       required debug
account    [default=bad success=ok user_unknown=ignore] debug
password   sufficient use_authtok debug
session required skel=/etc/skel umask=0022
session    requisite debug


Potential Issue:

If you run into a permission issue with the above configuration when users try to login, this could be caused by an incorrect parameter value in the sssd.conf file. The sssd.conf file could have the following parameter defined:

ldap_user_home_directory = unixHomeDirectory

But unixHomeDirectory might not be the correct attribute in your LDAP structure. You can use the following to get around this problem:


fallback_homedir = /home/%u
#ldap_user_home_directory = unixHomeDirectory


Notice that the second line is commented out. (It might actually work without commenting that out, as long as the fallback_homedir parameter is defined.)

Make sure to run the following commands after any change to your sssd.conf file:

sudo sss_cache -E
sudo service sssd restart