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.

  1. Hello Dmitri,

    Being completely unfamiliar with SSSD, I’m attempting to tackle an issue with getting SSSD installed from a Kickstart implementation for RHEL 7. I’ve opened a couple of tickets with RH, but I have never been able to resolve SSSD startup issues on RHEL 7 (after a Kickstart install of RHEL 7). After the RHEL 7 gets installed, I issue the command: “systemctl start sssd”.
    [root@rhel7 ~]# systemctl start sssd
    Job for sssd.service failed. See ‘systemctl status sssd.service’ and ‘journalctl -xn’ for details.
    [root@rhel7 ~]# systemctl status sssd
    sssd.service – System Security Services Daemon
    Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled)
    Active: failed (Result: exit-code) since Fri 2015-03-13 10:55:41 MDT; 9s ago
    Process 2438 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=4)
    .
    .
    .
    Mar 13 10:55:41 rhel7 systemd[1]: Failed to start System Security Services …
    Mar 13 10:55:41 rhel7 systemd[1]: Unit sssd.service entered failed state.

    Dmitri, does any of this look familiar? What could be missing?

  2. I am loving the level of polish in the RHEL 7 line. So many technologies are are now really fitting well together.

    Hopefully by the next point release of RHEL, Samba will be a supported IDM for deployment to manage our Windows boxes.

    1. This comment just showed up. It seems to be stuck somewhere. So the recommendation would be to open a RFE with Red Hat to include Samba 4 DC capability into IdM offering.

  3. Any idea when SSSD/CIFS integration functionality might be back-ported to Red Hat 6? I thought I read somewhere that this would be available in the sssd release with RHEL 6.7, but that does not appear to be the case (at least there is no sssd-libwbclient package)

    1. I think it was considered at some point but it is a big feature to back port and support in RHEL6 that is nearing its 8th minor release. If this is something you really need, please contact your Red Hat account representative or open a support case. This way we would be able to track this as a requirement. It does not mean it will be done but at least we would be able to assess how many customers need this and be able to prioritize accordingly.

      Thanks
      Dmitri

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s