DEBOPS.SSSD(5)

NAME
debops.sssd - Configure LDAP support for NSS and PAM lookups

SYNOPSIS

debops run service/sssd [--limit group,host,...] [--diff] [--check] [--tags tag1,tag2,...] [--skip-tags tag1,tag2,...] [<ansible-playbook options>] ...

DESCRIPTION

The sssd daemon, maintained by the SSSD Project <https://sssd.io/>, is a spinoff from the FreeIPA Project <https://www.freeipa.org/> and provides a modern take on venerable daemons such as debops.nslcd, debops.nscd and unscd(1) <https://manpages.debian.org/unscd(1)>. It is used to look up user, group or other information stored in a number of different databases, such as LDAP, Kerberos, FreeIPA, Active Directory, etc. It is needed if you want to use the posixAccount and posixGroup LDAP objects to authenticate to UNIX-like hosts.

The debops.sssd Ansible role can be used to configure the sssd service on a host and, via debops.ldap role, create a bind account in the LDAP directory used by sssd to perform LDAP lookups.

GETTING STARTED

  Example inventory

To enable the sssd service on a host, you need to add it to the [debops_service_sssd] Ansible inventory group. The host should also be configured with base LDAP support via the debops.ldap role (see its documentation for more details):

[debops_service_ldap]
hostname
[debops_service_sssd]
hostname

A common case is configuration of LDAP authentication in the entire cluster of hosts. You can enable debops.sssd role on all DebOps hosts in the Ansible inventory at once:

[debops_all_hosts]
hostname1
hostname2
[debops_service_sssd:children]
debops_all_hosts

The sssd service can also be installed and configured by other playbooks, for example bootstrap-sss.yml. In such cases the custom playbook will configure the sssd service on a host, but the role playbook will not work on a host automatically; you will have to include that host in the [debops_service_sssd] Ansible inventory group via one of the methods above to be able to change the service configuration.

  Example playbook

If you are using this role without DebOps, here's an example Ansible playbook that uses the debops.sssd role:

---
# SPDX-License-Identifier: GPL-3.0-only
- name: Manage sssd service
  collections: [ 'debops.debops', 'debops.roles01',
                 'debops.roles02', 'debops.roles03' ]
  hosts: [ 'debops_service_sssd' ]
  become: True
  environment: '{{ inventory__environment | d({})
                   | combine(inventory__group_environment | d({}))
                   | combine(inventory__host_environment  | d({})) }}'
  roles:
    - role: python
      tags: [ 'role::python', 'skip::python', 'role::ldap' ]
      python__dependent_packages3:
        - '{{ ldap__python__dependent_packages3 }}'
      python__dependent_packages2:
        - '{{ ldap__python__dependent_packages2 }}'
    - role: ldap
      tags: [ 'role::ldap', 'skip::ldap' ]
      ldap__dependent_tasks:
        - '{{ sssd__ldap__dependent_tasks }}'
    - role: sssd
      tags: [ 'role::sssd', 'skip::sssd' ]
    - role: nsswitch
      tags: [ 'role::nsswitch', 'skip::nsswitch' ]
      nsswitch__dependent_services:
        - '{{ sssd__nsswitch__dependent_services }}'

  Ansible tags

You can use Ansible --tags or --skip-tags parameters to limit what tasks are performed during Ansible run. This can be used after host is first configured to speed up playbook execution, when you are sure that most of the configuration has not been changed.

Available role tags:

role::sssd
    Main role tag, should be used in the playbook to execute all of the role tasks as well as role dependencies.

  Other resources

List of other useful resources related to the debops.sssd Ansible role:

•   Manual pages: sssd.conf(5) <https://manpages.debian.org/sssd.conf(5)> (and subsystem man pages such as sssd-ldap(5) <https://manpages.debian.org/sssd-ldap(5)> and sssd-krb5(5) <https://manpages.debian.org/sssd-krb5(5)>)

•   The website of the SSSD Project <https://sssd.io/>

•   LDAP support in DebOps: client-side, server-side

•   Configuring SSSD <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/sssd> in the Red Hat Enterprise Linux 7 Guide

•   Understanding SSSD <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/understanding-sssd-and-its-benefits_configuring-authentication-and-authorization-in-rhel> in the Red Hat Enterprise Linux 8 Guide

•   LDAP authentication <https://wiki.archlinux.org/index.php/LDAP_authentication> documentation in the Arch Wiki

•   Debian LDAP Portal <https://wiki.debian.org/LDAP> page in the Debian Wiki

DEFAULT VARIABLE DETAILS

Some of the debops.sssd default variables have more extensive configuration than simple strings or lists, here you can find documentation and examples for them.

  sssd__configuration

The sssd__*_configuration variables define the contents of the /etc/sssd/sssd.conf configuration file. The variables are merged in the order defined by the sssd__combined_configuration variable, which allows modification of the default configuration through the Ansible inventory. See sssd.conf(5) <https://manpages.debian.org/sssd.conf(5)> and the service-specific man pages (e.g. sssd-ldap(5) <https://manpages.debian.org/sssd-ldap(5)>, sssd-krb5(5) <https://manpages.debian.org/sssd-krb5(5)> or sssd-sudo(5) <https://manpages.debian.org/sssd-sudo(5)>) for possible configuration parameters and their values.

  Examples

See sssd__default_configuration variable for an example of existing configuration.

Enable debugging for the nss and pam subsystems:

sssd__configuration:
  - section: 'nss'
    options:
      - debug_level: '0x0770'
  - section: 'pam'
    options:
      - debug_level: '0x0770'

Enable enumeration (which means that sssd will download and cache all users and groups from the LDAP server preemptively). This means that users and groups will still be available in case of network outages, etc, but enumeration is not suitable for large environments:

sssd__configuration:
  - section: 'domain/default'
    options:
      - name: 'enumerate'
        value: True

  Syntax

The variables contain a list of YAML dictionaries, each dictionary can have the following parameters:

section
    Required. Name of the sssd.conf(5) <https://manpages.debian.org/sssd.conf(5)> configuration section in which a given configuration option should be included. This parameter is used as an "anchor", configuration entries with the same section are combined together and affect each other in order of appearance.

title
    Optional. This parameter can be used to provide a short description of the section which will be included in the generated configuration file.

state
    Optional. If not specified or present, a given section will be included in the generated configuration file. If absent, the section will not be included in the file. If ignore, a given configuration entry will not be evaluated during role execution. If hidden, the section's header and title will be hidden in the generated configuration file.

weight
    Optional. A positive or negative number which can be used to affect the order of sections in the generated configuration file. Positive numbers add more "weight" to the section making it appear "lower" in the file; negative numbers subtract the "weight" and therefore move the section upper in the file.

options
    Required. A list of sssd configuration options for a given section. The options parameters from configuration entries with the same section parameter are merged together in order of appearance and can affect each other.

    The options can be specified in a simple form as key/value pairs, where the key is the option name and value is the option value. Alternatively, if the name and value parameters are used, the entries can use an extended format with specific parameters:

name
    Required. The name of a given sssd.conf(5) <https://manpages.debian.org/sssd.conf(5)> configuration option for a given section. Options with the same section and name will be merged in order of appearance.

value
    Required. The value of a given configuration option. It can be either a string, a boolean, a number, or a YAML list (elements will be joined with commas).

raw Optional. String or YAML text block which will be included in the configuration file "as is". If this parameter is specified, the name and value parameters are ignored - you need to specify the entire line(s) with configuration option names as well.

state
    Optional. If not defined or present, a given configuration option or section will be included in the generated configuration file. If absent, ignore or init, a given configuration option or section will not be included in the generated file. If comment, the option will be included but commented out and inactive.

comment
    Optional. String or YAML text block that contains comments about a given configuration option.

AUTHOR
Maciej Delmanowski, David Härdeman

COPYRIGHT
2014-2024, Maciej Delmanowski, Nick Janetakis, Robin Schneider and others