Product Documentation

Set up SSSD

Sep 27, 2016

Use the information in this article to set up SSSD; 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.

Important

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:

  1. Join the domain and create host keytab with Samba
  2. Setup SSSD
  3. Configure NSS/PAM
  4. Verify the Kerberos configuration
  5. Verify user authentication

Required software

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:

  • RHEL 7.2/CentOS 7.2
  • Linux VDA versions 1.3, 1.4

Join the domain and create host keytab with Samba

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:

  • adcli
  • realmd
  • winbind
  • samba

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:

  • /etc/krb5.conf
  • /etc/samba/smb.conf:

Configure the machine for Samba and Kerberos authentication:

command 複製

sudo authconfig \

    --smbsecurity=ads \

    --smbworkgroup=domain \

    --smbrealm=REALM \

    --krb5realm=REALM \

    --krb5kdc=fqdn-of-domain-controller \

    --update

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:

command 複製

--enablekrb5kdcdns --enablekrb5realmdns

Open /etc/samba/smb.conf and add the following entries under the [Global] section, but after the section generated by the authconfig tool:

command 複製

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:

command 複製

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.

Setup SSSD

Setting up SSSD consists of the following steps:

  • install the sssd-ad package on the Linux client machine
  • make configuration changes to various files (for example, sssd.conf)
  • start the sssd service

/etc/sssd/sssd.conf

An example sssd.conf configuration (additional options can be added as needed):

command 複製

[sssd]

config_file_version = 2

domains = ad.example.com

services = nss, pam

 

[domain/ad.example.com]

# 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.comserver.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:

command 複製

chown root:root /etc/sssd/sssd.conf

chmod 0600 /etc/sssd/sssd.conf

restorecon /etc/sssd/sssd.conf

Configure NSS/PAM

RHEL/CentOS

Use authconfig to enable SSSD, install oddjob-mkhomedir to make sure home directory creation works with SELinux:

command 複製

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.

Verify the Kerberos configuration

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:

command 複製

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:

command 複製

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:

command 複製

sudo klist

Verify user authentication

Use the getent command to verify that the logon format it supported and whether the NSS works:

command 複製

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:

  • Down-level logon name: DOMAIN\username
  • UPN: username@domain.com
  • NetBIOS Suffix format: username@DOMAIN

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.

command 複製

sudo localhost –l DOMAIN\\username

id -u

Check that a corresponding Kerberos credential cache file was created for the uid returned by the command:

command 複製

ls /tmp/krb5cc_{uid}

Check that the tickets in the user’s Kerberos credential cache are valid and not expired:

command 複製

klist