Use the information in this article to set up SSSD on Red Hat and CentOS; it includes instructions for joining a Linux VDA machine to a Windows domain and provides guidance for configuring Kerberos authentication.
If you are using SSSD, follow the instructions contained in this section instead of the information provided by the Add Linux machine to Windows domain section.
This is an experimental feature and is provided by Citrix as a technical preview. Caution should be exercised when implementing this functionality in a production environment.
What is SSSD?
SSSD is a system daemon. It's primary function is to provide access to identify and authenticate remote resources through a common framework that can provide caching and offline support to the system. It provides both PAM and NSS modules, and in the future will support D-BUS based interfaces for extended user information. It also provides a better database to store local users as well as extended user data.
Setting up SSSD on RHEL and CentOS involves the following:
The Active Directory provider was first introduced with SSSD version 1.9.0. If you are using an older version, follow the instructions provided in configuring the LDAP provider with Active Directory.
The following environments have been tested and verified when using the instructions included in this article:
SSSD does not provide Active Directory client functions for joining the domain and managing the system keytab file. There are a few methods for achieving this, including:
The information in this section describes the Samba approach only. For realmd, refer to the Red Hat or CentOS documentation. These steps must be followed before configuring SSSD.
On the Linux client with properly configured files:
Configure the machine for Samba and Kerberos authentication:
sudo authconfig \
Where REALM is the Kerberos realm name in upper-case and domain is the short NetBIOS name of the Active Directory domain.
If DNS-based lookups of the KDC server and realm name is required, add the following two options to the above command:
Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:
kerberos method = secrets and keytab
Joining the Windows domain requires that your domain controller is reachable and you have a Active Directory user account with permissions to add computers to the domain:
sudo net ads join REALM -U user
Where REALM is the Kerberos realm name in upper-case, and user is a domain user with permissions to add computers to the domain.
Setting up SSSD consists of the following steps:
An example sssd.conf configuration (additional options can be added as needed):
config_file_version = 2
domains = ad.example.com
services = nss, pam
# Uncomment if you need offline logins
# cache_credentials = true
id_provider = ad
auth_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = ad
# Should be specified as the lower-case version of the long version of the Active Directory domain.
ad_domain = ad.example.com
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# Uncomment if service discovery is not working
# ad_server = server.ad.example.com
# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
Replace ad.domain.com, server.ad.example.com with the corresponding value. For more details, please refer to the sssd-ad(5) - Linux man page.
Set the file ownership and permissions on sssd.conf:
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
Use authconfig to enable SSSD, install oddjob-mkhomedir to make sure home directory creation works with SELinux:
authconfig --enablesssd --enablesssdauth --enablemkhomedir –update
sudo service sssd start
sudo chkconfig sssd on
When configuring Linux VDA settings, consider that for SSSD, there has no special settings for the Linux VDA client. For additional solutions in the ctxsetup.sh script, use the default value.
To verify Kerberos is configured correctly for use with the Linux VDA, check that the system keytab file has been created and contains valid keys:
sudo klist -ke
This should display the list of keys available for the various combinations of principal names and cipher suites. Run the Kerberos kinit command to authenticate the machine with the domain controller using these keys:
sudo kinit –k MACHINE\$@REALM
The machine and realm names must be specified in uppercase, and the dollar sign ($) must be escaped with a backslash (\) to prevent shell substitution. In some environments the DNS domain name is different from the Kerberos realm name; ensure the realm name is used. If this command is successful, no output is displayed.
Verify that the TGT ticket for the machine account has been cached using:
Use the getent command to verify that the logon format it supported and whether the NSS works:
sudo getent passwd DOMAIN\\username
The DOMAIN parameter should be the short version domain name, if another logon format from Citrix Receiver is needed, please verify by using the getent command first.
The supported logon formats are:
To verify that the SSSD PAM module is configured correctly, logon locally with a domain user account that has not logged onto the machine previously.
sudo localhost –l DOMAIN\\username
Check that a corresponding Kerberos credential cache file was created for the uid returned by the command:
Check that the tickets in the user’s Kerberos credential cache are valid and not expired: