Posit Connect - local unix account with LDAP authentication


I have a RSConnect Server where some of the shiny apps deployed there are getting data from cloudera odbc databases, which have kerberos authentication.

If I set the authentication to PAM, then from rsc content UI, I can change the rus as current user to "Use the Unix account of current user" and the connection to odbc databses works fine.

However the option "Use the Unix account of current user" is only available for PAM authentication but I need to use LDAP.

In short, I need to run shiny apps with the unix account of the user who is running the app.

Is there any work arround to the above problem?

Thank you in advance!

You are on the right track! The way forward would be:

Thank you for your response.
Forgot to mentioned that I need multiple (2 or more) AD to communicate with RSC Server and this is the reason I used LDAP authentication. So, in the solution you proposed, can I join more than one AD to Linux Server?

Yes, sssd can use more than one AD server. It is actually more flexible than Connect in this regard, since it does not pose any restrictions w.r.t. the layout of the LDAP tree. Resources:

So my understanding is that there is no work around to what I want to do if I want to use LDAP as authentication mechanism for rsc server. The only way to do it, is to add the Ads with realm and use PAM as authentication mech in rsc server, correct?

Unfortunately, yes - the workarounds here get a bit unfortunate if you want RunAsCurrentUser and LDAP auth. We will definitely pass this feedback on to the team!! We would love to have a more flexible runAsCurrentUser feature someday.

The workarounds generally take the flavor of something akin to:

  • use keytabs associated with different accounts for each of the applications, since no PAM session / context will be available from the user's authentiction
  • set per-app runAsUser service accounts. Does not accomplish "for different viewers"
  • build helpers into your applications that behave in a more "kerberos aware fashion" and can impersonate users based on session$user and whoever is authenticated to the application.

EDIT: Just to be clear, when I say "LDAP Auth" above, I mean Connect's "direct LDAP integration." If you integrate your server with sssd as @rstub mentions above, then users will still use their LDAP credentials to login, but Connect will be using "PAM Auth" from its point of view.

Why do you want to use Connect's LDAP integration for authentication? With Connect's PAM integration together with sssd integrating with AD you will end up with the same usernames and passwords.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.