Product Documentation

Integrate NIS with Active Directory

May 22, 2017

This article describes how to integrate NIS with Windows Active Directory (AD) on 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 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.

Note

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.

Tip

This method represents a deprecated way to deploy the Linux VDA, which should only be used for special use cases. For an RHEL/CentOS distribution, follow the instructions here. For an Ubuntu distribution, follow the instructions here.

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 AD provider was first introduced with SSSD Version 1.9.0. If you are using an earlier version, follow the instructions provided in Configuring the LDAP provider with AD.

The following environments have been tested and verified when using the instructions included in this article:

  • RHEL 7.2 or later/CentOS 7.2 or later
  • Linux VDA Version 1.3 or later

Integrate NIS with AD

Add the Linux VDA as a NIS client

Configure the NIS client:

command Copy

yum –y install ypbind rpcbind oddjob-mkhomedir

Set the NIS domain:

command Copy

ypdomainname nis.domain

echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network

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

command Copy

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

Configure NIS by authconfig:

command Copy

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 Copy

sudo systemctl start rpcbind ypbind

sudo systemctl enable rpcbind ypbind 

Ensure that the NIS configuration is correct:

command Copy

ypwhich

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

command Copy

getent passwd nisaccount

Note

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 AD 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, see the RHEL or CentOS vendor's documentation. These steps must be followed before configuring SSSD.

Join the domain and create host keytab with Samba

On the Linux client with properly configured files:

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

Configure the machine for Samba and Kerberos authentication:

command Copy

sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update

Where REALM is the Kerberos realm name in uppercase 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 Copy

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

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 Copy

sudo net ads join REALM -U user

Where REALM is the Kerberos realm name in uppercase, and user is a domain user with permissions to add computers to the domain.

Set up SSSD

Setting up SSSD consists of the following steps:

  • install the sssd-ad and sssd-proxy packages 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):

Config Copy

 

[sssd]

config_file_version = 2

domains = example

services = nss, pam

 

[domain/example]

# Uncomment if you need offline logins

# cache_credentials = true

re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))

id_provider = proxy

proxy_lib_name = nis

auth_provider = ad

access_provider = 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 Copy

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 Copy

authconfig --enablesssd --enablesssdauth --enablemkhomedir --update

sudo systemctl start sssd

sudo systemctl enable sssd

Tip

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 Copy

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 Copy

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 Copy

sudo klist -ke

Verify user authentication

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

command Copy

sudo getent passwd DOMAIN\\username

The DOMAIN parameter should be the short version domain name. If another logon format from Citrix Receiver is needed, 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, log on locally with a domain user account that has not previously logged on to the machine.

command Copy

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 Copy

ls /tmp/krb5cc_{uid}

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

command Copy

klist