Product Documentation

Integrate NIS with Active Directory

Sep 27, 2016

This topic describes how to integrate NIS with Windows Active Directory (AD)  in the Linux VDA by using SSSD. The Linux VDA is considered a component of Citrix XenApp & XenDesktop. As a result, it fits tightly into the Windows Active Directory (AD) environment. 

Using NIS as a UID and GID provider instead of using AD requires that the account information (username and password combinations) is the same in, both, AD and NIS.

注意

Authentication is still performed by the AD server. NIS+ is not supported. If you use NIS as the UID and GID provider, the POSIX attributes from the Windows server are no longer used.

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. Its 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 user accounts and extended user data.

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

Integrating NIS with Active Directory

Add the Linux VDA as a NIS client

Configure the NIS client:

command 複製

yum –y install ypbind rpcbind oddjob-mkhomedir

Set the NIS domain:

command 複製

ypdomainname nis.domain

echo “NISDOMAIN=nis.domain” >> /etc/sysconfig/network

Add the IP address for the NIS server and client in /etc/hosts:

command 複製

{NIS server IP address}   server.nis.domain nis.domain

Configure NIS by authconfig:

command 複製

sudo authconfig \

     --enablenis \

     --nisdomain=nis.domain \

     --nisserver=server.nis.domain \

     --enablemkhomedir \

     --update

nis.domain represents the domain name of the NIS server, and server.nis.domain is the hostname of the NIS server, which can also be the IP address of the NIS server.

Configure the NIS services:

command 複製

sudo systemctl start rpcbind ypbind

sudo systemctl enable rpcbind ypbind 

Ensure that the NIS configuration is correct:

command 複製

ypwhich

Validate that the account information is available from the NIS server:

command 複製

getent passwd nisaccount

nisaccount represents the real NIS account on the NIS server. Make sure that the UID, GID, home directory, and login shell are configured correctly.

Join the domain and create a 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 AD 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 your domain controller to be reachable and that you have an AD 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.com, server.ad.example.com with the corresponding value. For more details, see 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 systemctl start sssd

sudo systemctl enable sssd

提示

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 -ke

Verify user authentication

Use the getent command to verify that the logon format is 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 previously logged on to the machine.

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