Configure Active Directory with SSSD

Overview

This guide walks you through integrating Posit Workbench with Microsoft Active Directory (AD) using System Security Services Daemon (SSSD) for authentication and automatic user provisioning.

The AD reference page covers AD integration options comprehensively. This guide takes a single, recommended path through those options, making specific choices at each step. You can go from a fresh installation to working AD authentication with minimal decisions.

What you will accomplish

By the end of this guide, your Workbench server will:

Authenticate users against your AD domain.
Automatically provision user accounts and home directories on first login.
Optionally test Kerberos ticket acquisition for downstream resource access.

Prerequisites

Before you begin, ensure you have:

Workbench: Installed and accessible. You must have administrative command line access to the Workbench server.
AD domain: A functioning AD domain you can join.
DNS resolution: The Workbench server can resolve AD domain names.
Time synchronization: Network Time Protocol (NTP) or Chrony configured (Kerberos requires less than 5 minutes of clock skew).
Admin credentials: An AD account with permission to join endpoints to the domain.
Firewall rules: Ports 53, 88, 389, 445, 464, and 3268 (Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)) open to Domain Controllers.

Step 1: Install required packages

Terminal

sudo dnf install -y \
  realmd \
  sssd \
  adcli \
  oddjob \
  oddjob-mkhomedir \
  krb5-workstation

Terminal

sudo apt update
sudo apt install -y \
  realmd \
  sssd \
  sssd-tools \
  adcli \
  libnss-sss \
  libpam-sss \
  krb5-user

This guide uses realmd because it automates domain joining: it configures Kerberos, SSSD, and Pluggable Authentication Modules (PAM) in a single command.

Step 2: Verify DNS and domain discovery

Before joining, confirm that your server can discover the AD domain:

Terminal

realm discover YOUR-DOMAIN.COM

Expected output:

your-domain.com
  type: kerberos
  realm-name: YOUR-DOMAIN.COM
  domain-name: your-domain.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: adcli
  required-package: samba-common-bin

If discovery fails

If realm discover fails, check:

DNS: Can you resolve the domain? Run nslookup YOUR-DOMAIN.COM.
Network: Can you reach the Domain Controller? Run nc -zv dc.your-domain.com 389.
Time: Is your clock synchronized? Run timedatectl status.

Step 3: Join the domain

Join your Workbench server to the AD domain:

Terminal

sudo realm join --user=Administrator YOUR-DOMAIN.COM

The system prompts you for the AD administrator password. After a successful join, verify:

Terminal

realm list

Expected output:

your-domain.com
  type: kerberos
  realm-name: YOUR-DOMAIN.COM
  domain-name: your-domain.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  ...

Step 4: Configure SSSD for Workbench compatibility

The realm join command creates a default SSSD configuration that needs adjustments to work with Workbench. Open /etc/sssd/sssd.conf in an editor, locate the [domain/your-domain.com] section, and configure the following settings (add or modify as needed):

/etc/sssd/sssd.conf

[domain/your-domain.com]
# ... existing configuration from realm join ...

# Use short usernames and matching home directories
use_fully_qualified_names = False
fallback_homedir = /home/%u

# Enable AD-based access control
access_provider = ad
ad_gpo_map_service = +rstudio

# Optional: Restrict access to specific AD security group
# ad_access_filter = (memberOf=CN=rstudio-users,OU=YourOU,DC=your-domain,DC=com)

# Performance tuning for large directories
enumerate = False
ignore_group_members = True

# Cache credentials for offline authentication
cache_credentials = True

# Extend Kerberos ticket lifetime for long-running jobs
krb5_renewable_lifetime = 7d
krb5_renew_interval = 60m

Critical SSSD settings

use_fully_qualified_names = False: Allows users to log in with just their username instead of username@domain.com.

ad_gpo_map_service = +rstudio: This is the most common cause of “authentication succeeds but login fails” errors. By default, SSSD enforces AD Group Policy Objects (GPO). This setting explicitly allows the PAM service rstudio through GPO.

ad_access_filter: Optional but recommended. Restricts Workbench access to members of a specific AD security group. Replace the example with your actual group DN.

After editing, set proper file permissions (SSSD requires strict permissions):

Terminal

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf

Restart SSSD to apply changes:

Terminal

sudo systemctl restart sssd

Verify that SSSD restarted successfully:

Terminal

sudo systemctl status sssd

Step 5: Configure home directory creation

Workbench relies on users having valid home directories. Configure PAM to create these automatically on first login.

On RHEL-based systems, use oddjob-mkhomedir to ensure proper Security-Enhanced Linux (SELinux) contexts:

Terminal

sudo systemctl enable --now oddjobd
sudo authselect select sssd with-mkhomedir --force

On SELinux-enabled systems (the RHEL default), pam_mkhomedir creates directories with incorrect security contexts, causing Permission Denied errors. oddjob-mkhomedir creates directories with proper SELinux labels.

Terminal

sudo apt update
sudo apt install -y libpam-modules
sudo pam-auth-update --enable mkhomedir

Step 6: Configure Workbench settings

Create the PAM authentication profile that Workbench uses for login. Home directory creation happens separately through PAM sessions, which default to /etc/pam.d/su (configurable with auth-pam-sessions-profile).

Terminal

sudo cp --backup /etc/pam.d/login /etc/pam.d/rstudio

Terminal

sudo cp --backup /etc/pam.d/other /etc/pam.d/rstudio

Edit /etc/rstudio/rserver.conf and add the following line if it is not already present:

/etc/rstudio/rserver.conf

# Enable PAM sessions for home directory creation
auth-pam-sessions-enabled=1

This enables PAM sessions, which trigger automatic home directory creation on first login.

Step 7: Restart Workbench

Apply the configuration by restarting Workbench:

Terminal

sudo rstudio-server restart

Verify that Workbench restarted successfully:

Terminal

sudo systemctl status rstudio-server

Validation

Test your configuration with these commands.

1. Verify user lookup

Terminal

id username

Expected output:

uid=1234567(username) gid=1234567(domain users) groups=...

The command returns user information without requiring the @domain.com suffix. If this fails, verify that use_fully_qualified_names = False is set in /etc/sssd/sssd.conf and that SSSD has been restarted.

2. Test Kerberos authentication

Terminal

kinit username@YOUR-DOMAIN.COM
klist

Expected output:

Ticket cache: <location>
Default principal: username@YOUR-DOMAIN.COM

Valid starting     Expires            Service principal
06/10/26 09:30:07  06/11/26 09:30:07  krbtgt/YOUR-DOMAIN.COM@YOUR-DOMAIN.COM

Note

This method of creating a Kerberos ticket is suitable for testing and one-off use. For regular use, automate ticket creation. This topic is outside the scope of this guide.

3. Verify PAM configuration

Terminal

sudo /usr/lib/rstudio-server/bin/pamtester --verbose rstudio username \
     authenticate acct_mgmt setcred open_session close_session

If the authentication step succeeds but the account management step fails, this typically indicates an SSSD access control issue. See Troubleshooting.

4. Test Workbench login

Open your browser to http://your-workbench-server:8787.
Log in with AD credentials using just the username (not username@domain.com).
Verify that the system created a home directory:
```
Terminal
```
```
ls -la /home/username/
```

Troubleshooting

Understanding access control layers

SSSD implements multiple layers of access control. PAM authentication success does not guarantee login success. Users must pass through all of these layers:

PAM authentication: Verifies credentials.
SSSD access_provider: Checks whether the user has access.
Access filters: Optional group membership checks (ad_access_filter).
Group Policy Objects (GPO): AD policy enforcement.

Each layer can independently deny access. Check logs at each layer when troubleshooting.

Login fails after successful authentication (GPO issues)

Symptoms: The authentication step in pamtester succeeds, but the account management step and web login fail with Permission denied or Access denied.

Log indicators: Look in /var/log/sssd/sssd_<your-domain>.log for:

[ad_gpo_access_send] service rstudio maps to Denied
[ad_gpo_access_done] GPO-based access control failed.

Solution: Set ad_gpo_map_service = +rstudio in /etc/sssd/sssd.conf and restart SSSD:

Terminal

sudo systemctl restart sssd

This is the most common cause of authentication succeeding, but login failing with AD integration.

Username format mismatch

Symptoms: User lookup requires the full User Principal Name (UPN) (username@domain.com) but Workbench login with the short name fails.

Solution: Ensure use_fully_qualified_names = False is set in /etc/sssd/sssd.conf, then restart SSSD:

Terminal

sudo systemctl restart sssd

Verify with both:

Terminal

id username
id username@your-domain.com

Both commands return the same user information using the short username.

User lookup fails (`id` returns “no such user”)

Check SSSD configuration and logs:

Terminal

sudo sss_cache -E
sudo systemctl restart sssd
sudo systemctl status sssd
sudo journalctl -u sssd -f

Check domain-specific logs:

Terminal

sudo tail -f /var/log/sssd/sssd_<your-domain>.log

Access denied errors

Check the three key log files:

/var/log/rstudio/rstudio-server/rserver.log for Workbench application errors.
/var/log/auth.log (Ubuntu) or /var/log/secure (RHEL) for PAM authentication details.
/var/log/sssd/sssd_<your-domain>.log for SSSD access control decisions.

Look for error messages containing:

pam_sss(rstudio:account): Access denied
GPO-based access control failed
Permission denied

SSSD does not start after editing configuration

Check file permissions:

Terminal

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
sudo systemctl restart sssd
sudo systemctl status sssd

Look for duplicate configuration entries in /etc/sssd/sssd.conf. Each setting must appear only once in the domain section.

Login is slow (more than 30 seconds)

Large AD directories can cause slow lookups. Ensure these settings are in /etc/sssd/sssd.conf:

/etc/sssd/sssd.conf

enumerate = False
ignore_group_members = True

Clock skew errors

Kerberos requires synchronized time (within 5 minutes). Verify that NTP is configured:

Terminal

timedatectl status

The output displays “System clock synchronized: yes”. If it does not:

Terminal

sudo systemctl enable --now chronyd

Terminal

sudo systemctl enable --now systemd-timesyncd

Summary

The steps in this guide configured Workbench to:

Authenticate users against Active Directory.
Automatically provision user accounts on first login.
Create home directories with proper permissions.
Optionally test Kerberos ticket acquisition.

Key choices made in this guide

Decision	Choice	Reason
Domain join tool	`realmd`	Automates Kerberos, SSSD, and PAM configuration.
Authentication daemon	`sssd`	Well-supported, handles caching and offline authentication.
Home directory creation (RHEL)	`oddjob-mkhomedir`	Creates directories with proper SELinux contexts.
Home directory creation (Ubuntu)	`pam_mkhomedir`	Standard approach for non-SELinux systems.

Overview

What you will accomplish

Prerequisites

Step 1: Install required packages

Step 2: Verify DNS and domain discovery

Step 3: Join the domain

Step 4: Configure SSSD for Workbench compatibility

Step 5: Configure home directory creation

Step 6: Configure Workbench settings

Step 7: Restart Workbench

Validation

1. Verify user lookup

2. Test Kerberos authentication

3. Verify PAM configuration

4. Test Workbench login

Troubleshooting

Understanding access control layers

Login fails after successful authentication (GPO issues)

Username format mismatch

User lookup fails (id returns “no such user”)

Access denied errors

SSSD does not start after editing configuration

Login is slow (more than 30 seconds)

Clock skew errors

Summary

Key choices made in this guide

Related resources

User lookup fails (`id` returns “no such user”)