Integrate NIS with Active Directory
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 Virtual Apps and Desktops. As a result, it fits tightly into the Windows AD environment.
Using NIS instead of AD as a UID and GID provider requires the account information (user name and password combinations) to be the same in 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 in Install Linux Virtual Delivery Agent for RHEL/CentOS. For an Ubuntu distribution, follow the instructions in Install Linux Virtual Delivery Agent for Ubuntu.
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.
Integrate NIS with AD
To integrate NIS with AD, complete the following steps:
Step 1: Add the Linux VDA as a NIS client
Configure the NIS client:
yum –y install ypbind rpcbind oddjob-mkhomedir
<!--NeedCopy-->
Set the NIS domain:
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
<!--NeedCopy-->
Add the IP address for the NIS server and client in /etc/hosts:
{NIS server IP address} server.nis.domain nis.domain
Configure NIS by authconfig:
sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update
<!--NeedCopy-->
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:
sudo systemctl start rpcbind ypbind
sudo systemctl enable rpcbind ypbind
<!--NeedCopy-->
Ensure that the NIS configuration is correct:
ypwhich
<!--NeedCopy-->
Validate that the account information is available from the NIS server:
getent passwd nisaccount
<!--NeedCopy-->
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.
Step 2: Join the domain and create a host keytab using 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:
adclirealmdWinbindSamba
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 using Samba:
On the Linux client with properly configured files:
- /etc/krb5.conf
- /etc/samba/smb.conf:
Configure the machine for Samba and Kerberos authentication:
sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy-->
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:
--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:
kerberos method = secrets and keytab
winbind offline logon = no
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:
sudo net ads join REALM -U user
<!--NeedCopy-->
REALM is the Kerberos realm name in uppercase and user is a domain user who has permissions to add computers to the domain.
Step 3: 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):
[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 long version of the Active Directory domain.
ad_domain = 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
<!--NeedCopy-->
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:
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
Step 4: Configure NSS/PAM
RHEL/CentOS:
Use authconfig to enable SSSD. Install oddjob-mkhomedir to ensure that the home directory creation is compatible with SELinux:
authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
Tip:
When configuring Linux VDA settings, consider that for SSSD, there has no special settings for the Linux VDA client. For extra solutions in the ctxsetup.sh script, use the default value.
Step 5: 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:
sudo klist -ke
<!--NeedCopy-->
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:
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
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:
sudo klist -ke
<!--NeedCopy-->
Step 5: Verify user authentication
Use the getent command to verify that the logon format is supported and whether the NSS works:
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
The DOMAIN parameter indicates the short version domain name. If another logon format 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.
sudo ssh localhost –l DOMAIN\\username
id -u
<!--NeedCopy-->
Check that a corresponding Kerberos credential cache file was created for the uid returned by the command:
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
Check that the tickets in the user’s Kerberos credential cache are valid and not expired:
klist
<!--NeedCopy-->