New SSSD Features in Red Hat Enterprise Linux 7.1

This post is dedicated to the new SSSD features in Red Hat Enterprise Linux 7.1 that have significance when SSSD is used by itself (i.e. without IdM integration) – for example, when connecting directly to Active Directory (AD) or some other Directory Server.

Control Access to Linux Machines with Active Directory GPO

A common use case for managing computer-based access control in an Active Directory environment is through the use of GPO policy settings related to Windows Logon Rights. The Administrator who maintains a heterogeneous AD and Red Hat Enterprise Linux network without an IdM server has traditionally had to face the challenging task of centrally controlling access to the Linux machines without being able to update the SSSD configuration on each and every client machine.

In Red Hat Enterprise Linux 7.1, the Administrator is (now) able to

define log-in policies in a central place -- on the Active Directory Domain Controller in the Group Policy. The same policies will then be honored by its Red Hat Enterprise Linux clients and Windows clients alike. For additional technical details on centrally controlling access to Linux machines with AD GPO click here.

Integrate SSSD with CIFS Client

Although mapping of POSIX UIDs and SIDs is not needed when mounting a Samba CIFS share, it might become necessary when working with files on the share (e.g. when modifying ACLs). Up to version 5.8 the cifs-utils package used winbind for this exclusively. However, with version 5.9 of cifs-utils, a plugin interface was introduced to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs.

In Red Hat Enterprise Linux 7.1, SSSD provides a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin, an SSSD client can access a CIFS share with the same functionality as a client running winbind. For additional technical details, visit the SSSD design page.

Active Directory Users Can Use UPN to Log In

Kerberos authentication is independent of the operating system of the host and the Kerberos principals are intentionally decoupled from the user identity and respective POSIX information. Basic mappings are integrated in the MIT Kerberos library - by default, the realm part of the Kerberos principal is stripped off and what remains is considered a POSIX user name. However, the mapping does not suit environments with multiple realms or a Cross-Realm Trust with the Active Directory. Manual auth_to_local rules need to be defined on all supported client systems in this case.

SSSD in Red Hat Enterprise Linux 7.1 introduces a local auth plugin for Kerberos KDC to allow SSSD to look up the POSIX information for an authenticated account and return it to the system. No auth_to_local rules need to be configured for configured realms in SSSD. As above, to review additional technical details, visit the respective SSSD design page.

Restricting the Domains a PAM Service Can Authenticate Against

Some environments require that different PAM applications can use a different set of SSSD domains. The legacy PAM modules, such as pam_ldap were able to use a different configuration file altogether as a parameter for the PAM module. An example use-case is an environment that allows external users to authenticate to an FTP server. This server is running as a separate non-privileged user and should only be able to authenticate to a selected SSSD domain, separate from the internal company accounts.

With SSSD in Red Hat Enterprise Linux 7.1, the Administrator is able to leverage this new feature to allow the FTP user to only authenticate against one of the domains in the FTP PAM config file. Additional information on how to restrict the domains a PAM service can authenticate against can be found here.

Running SSSD As a Non-Root User

Normally, all SSSD processes run as the root user. However, if one of the processes was compromised, it might lead to compromising the whole system, especially if additional measures like SELinux were not enabled. In Red Hat Enterprise Linux 7.1, except several well documented parts, all SSSD processes are able to be run as an unprivileged user when the user option is configured in sssd.conf. And, yes, once again, for additional information on how most SSSD can now be run as an unprivileged user I encourage you to visit the respective SSSD design page.