Configuring Active Directory in Posit Workbench#
RStudio is now Posit!
Our professional products have been renamed to Posit Connect, Posit Workbench, Posit Package Manager, Posit Cloud, and Posit Academy so it’s easier for folks to understand that we support more than just R. Please review our Blog post/FAQ to answer commonly asked questions about the rebrand.
Caution
This section is a suggested set of steps that may not be appropriate for your configuration. Therefore, you may have to make changes to the steps below for your specific configuration. This content is not meant to be a step-by-step guide that works across all configurations.
Posit Workbench, formerly RStudio Workbench, can be configured to use Active Directory (AD) as the user authentication service, which allows users to authenticate to Workbench via their AD credentials.
This setup requires the machine with Workbench to be joined to a Windows domain, and it requires configuring PAM to use AD as its identity provider. This configuration allows AD accounts to be used along with local system accounts. Workbench requires the use of local system accounts regardless of the authentication method that is used.
This setup can be configured in many different ways and is typically governed by the systems and services that your organization already has in place.
This
document describes the process of integrating Workbench with AD using
realmd
and sssd
. For alternative methods of configuration, refer to the Red
Hat
and Ubuntu documentation.
For more information on how Workbench works with PAM sessions, refer to the Workbench Administrator Guide.
Prerequisites#
This article assumes that you have an Active Directory server. In this example,
the Windows server is configured with a hostname of
winserver.demo.rstudioservices.com
:
Active Directory configurations outside of Posit products is not supported
Posit does not provide support for Active Directory configurations outside of Posit products.
The hostname of the AD server should be resolvable by all of the servers that you want to join to the Windows domain. For this example, the Linux machine where Workbench is installed should be able to resolve the AD hostname.
$ nslookup winserver.demo.rstudioservices.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: winserver.demo.rstudioservices.com
Address: 172.31.31.231
You should also have Workbench installed with the default configuration that uses local system accounts.
Join AD domain#
Supported Linux operating systems
The steps outlined below are examples of how to join an Active Directory domain in RHEL/CentOS 7 and Ubuntu 18.04 operating systems. The steps should be similar for other versions of RHEL/CentOS and Ubuntu but may not be identical.
Posit Workbench supports more than the operating systems shown in the examples below. For a full list visit the Posit Platform Support page.
-
Install the LDAP client system dependencies for your Linux distribution:
$ sudo yum install realmd oddjob oddjob-mkhomedir sssd adcli samba-common \ samba-common-tools krb5-workstation openldap-clients policycoreutils-python
$ sudo apt-get install realmd sssd sssd-tools samba-common krb5-user \ packagekit samba-common-bin samba-libs adcli ntp
-
Use the following
realm join
command to join the AD domain. In this example, we are using theAdministrator
user on AD (you will be prompted for the password):Terminal$ sudo realm join -v -U Administrator winserver.demo.rstudioservices.com [... truncated output ...] * Successfully enrolled machine in realm
-
Confirm the connection by running the
realm list
command:Terminal$ realm list demo.rstudioservices.com type: kerberos realm-name: DEMO.RSTUDIOSERVICES.COM domain-name: demo.rstudioservices.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: sssd-tools required-package: sssd required-package: libnss-sss required-package: libpam-sss required-package: adcli required-package: samba-common-bin login-formats: %U@demo.rstudioservices.com login-policy: allow-realm-logins
-
You can use the
id
andgetent
commands to verify that the users on the AD domain can be used on the machine with Workbench, for example:Terminal$ id administrator@demo.rstudioservices.com uid=1684800500(administrator@demo.rstudioservices.com) gid=1684800513(domain users@demo.rstudioservices.com) groups=1684800513(domain users@demo.rstudioservices.com), 1684800520(group policy creator owners@demo.rstudioservices.com), 1684800518(schema admins@demo.rstudioservices.com), 1684800512(domain admins@demo.rstudioservices.com), 1684800572(denied rodc password replication group@demo.rstudioservices.com), 1684800519(enterprise admins@demo.rstudioservices.com) $ getent passwd administrator@demo.rstudioservices.com administrator@demo.rstudioservices.com:*:1684800500:1684800513: Administrator:/home/administrator@demo.rstudioservices.com:/bin/bash
Information on joining an AD domain with realmd
The process of joining the AD domain with realmd
resulted in the following
changes to the system:
- Joined the domain by creating an account entry for the system in the directory.
- Created the
/etc/krb5.keytab
host keytab file. - Configured the domain in SSSD and restarted the service.
- Enabled domain users for the system services in PAM configuration and the
/etc/nsswitch.conf
file.
If you want to configure these items manually, then refer to the documentation described in the PAM Sessions section of the Workbench Administrator Guide.
UID and GID
The default configuration created by realm
uses LDAP ID mapping. For more
details on using POSIX attributes such as UIDs and GIDs, refer to the
sssd.conf(5) man page
or external SSSD
documentation.
Configure home directory creation#
By default, users from the AD domain will not have a home directory on the Linux server. Because sessions in Workbench require that the user's home directories are present, we will configure PAM sessions to automatically create the home directories.
-
In the PAM session configuration file located at
/etc/pam.d/common-session
, locate the line that containssession required pam_unix.so
, and add the following line immediately below it:File: /etc/pam.d/common-sessionsession required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
-
You can test the automatic creation of home directories by switching to an AD user using the
su
orssh
commands:Terminal$ su administrator@demo.rstudioservices.com Password: Creating directory '/home/administrator@demo.rstudioservices.com'. $ ssh -l testuser@demo.rstudioservices.com linux-client
Customizing the location of home directories for AD users
By default, home directories will be created in
/home
.To customize the directory location or template, edit the
/etc/sssd/sssd.conf
file by adding theoverride_homedir
option in the target domain. This is useful when configuring user data in Workbench in a different location (e.g., when working with an NFS server).For example, the following configuration can be used in
/etc/sssd/sssd.conf
to specify a home directory location of/usr/home/{ domain_name }/{ user_name }
:File: /etc/sssd/sssd.conf[domain/demo.rstudioservices.com] [... file truncated ...] override_homedir = /usr/home/%d/%u
For additional details on SSSD configuration options, refer to the sssd.conf(5) man page.
Configure PAM profile#
-
Now that the system with Workbench is configured for authentication via AD users, you can copy the
login
PAM profile for use with Workbench:Terminal$ cp /etc/pam.d/login /etc/pam.d/rstudio
-
You can test your updated PAM configuration outside of Workbench using the provided
pamtester
utility:Terminal$ sudo /usr/lib/rstudio-server/bin/pamtester --verbose rstudio testuser@demo.rstudioservices.com authenticate acct_mgmt setcred open_session close_session pamtester: invoking pam_start(rstudio, testuser@demo.rstudioservices.com, ...) pamtester: performing operation - authenticate Password: [... truncated output ...] pamtester: successfully opened a session pamtester: performing operation - close_session pamtester: session has successfully been closed
If a
pam_acct_mgmt
error is observed with the following outputpamtester: successfully authenticated pamtester: performing operation - acct_mgmt pamtester: Permission denied
Edit the
/etc/pam.d/common-account
configuration file to remove account checking from thepam_sss
module by commenting out the following line:[... truncated file ...] # account [default=bad success=ok user_unknown=ignore] pam_sss.so
For more information on the pamtester
utility, refer to the Testing and
Troubleshooting
section of the Workbench Administration Guide.
Log in to Workbench#
You should now be able to log into Workbench using Active Directory users.
-
To log in, use the format
username@domain
for the username and the corresponding password.
Generating Kerberos tickets#
If you installed all of the required dependencies, and a Kerberos Key
Distribution Center (KDC) is available on the Windows domain, then you should
have access to generate Kerberos tickets from within sessions in Workbench by using the kinit
command.
-
In a terminal, for example, run:
kinit testuser@DEMO.RSTUDIOSERVICES.COM
-
You can also run this command from within the Terminal pane in Workbench: