Product Documentation

Integrate NIS with Active Directory

Feb 26, 2018

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 (user name 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 is used only 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 for the system. It provides both PAM and NSS modules, and in the future can 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.3 or later/CentOS 7.3 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

The nis.domain represents the domain name of the NIS server. The server.nis.domain is the host name 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

The nisaccount represents the real NIS account on the NIS server. Ensure 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 the functions, 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 NetBIOS name of the domain.

If DNS-based lookup of the KDC server and realm name is required, add the following two options to the preceding 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 that your domain controller is reachable and you have an AD user account with permissions to add computers to the domain:

Command Copy

sudo net ads join REALM -U user

REALM is the Kerberos realm name in uppercase and user is a domain user who has 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 (more 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 ensure that the home directory creation is compatible 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 ensure that 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 command displays 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. 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 that 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 indicates 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, use a domain user account to log on to the Linux VDA. The domain user account has not been used before.

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