AD for Debian with SaltStack – Part 3 – SSSD, PAM and sudo

This post finishes off the key parts of the AD configuration.

Installs SSSD – the System Security Services Daemon

sssd-pkg:
  pkg.installed:
    - name: sssd

Adds the SSSD configuration file

sssd-conf:
  file.managed:
    - name: /etc/sssd/sssd.conf
    - source: salt://common/ad/sssd.conf
    - user: root
    - group: root
    - mode: '0600'
    - template: jinja

The file sssd.conf is listed below.

Update nsswitch.conf

Updating the relevant lines to use sssd.

nsswitch-conf-add-sss:
  file.replace:
    - name: /etc/nsswitch.conf
    - pattern: '^(passwd: +compat|group: +compat|netgroup: +nis)$'
    - repl: '1 sss'
    - require:
      - sssd-pkg

SSSD package installer adds sss to the sudoers line which results in spurious security emails so we need to take this out.

nsswitch-conf-rm-sss:
  file.replace:
    - name: /etc/nsswitch.conf
    - pattern: '^(sudoers: +files) +sss$'
    - repl: '1'
    - require:
      - nsswitch-conf-add-sss

PAM

Add PAM configuration to create user home directories on login and run pam-auth-update to add our configuration file to the main configuration.

pam-conf:
  file.managed:
    - name: /usr/share/pam-configs/ad
    - source: salt://common/ad/pam-configs/ad
    - user: root
    - group: root
    - mode: '0644'
  cmd.run:
    - name: /usr/sbin/pam-auth-update --package
    - onchanges:
      - file: /usr/share/pam-configs/ad

The pam-configs/ad file is shown below.

sudo permission for Linux Admins AD Group

sudo-linux-admins:
  file.managed:
    - name: /etc/sudoers.d/ad-linux-admins
    - contents: '%Linux Admins ALL = (ALL) ALL'
    - user: root
    - group: root
    - mode: '0640'

Start up smbd

smbd-service:
  service.running:
    - name: smbd
    - enable: True
    - watch:
      - samba-conf

Note that sssd won’t start up until we’ve joined the domain. You will see the following lines in the logs from the installation startup:

/var/log/sssd/sssd.log:

[sssd] [load_configuration] (0x0010): ConfDB initialization has failed [Missing configuration file]
[sssd] [main] (0x0020): Configuration file: /etc/sssd/sssd.conf does not exist.
[sssd] [mt_svc_exit_handler] (0x0010): Process [DEV.GUESTLINE.NET], definitely stopped!

/var/log/sssd/sss_.log:

[load_backend_module] (0x0010): Error (2) in module (ad) initialization (sssm_ad_id_init)!
[be_process_init] (0x0010): fatal error initializing data providers
[main] (0x0010): Could not initialize backend [2]

These errors can be ignored until you’ve joined the domain. After that something is wrong!

Joining the domain

I haven’t yet integrated the domain join with Saltstack – this is still something that needs to be run manually using the script in the earlier post.

Configuration Files

/srv/salt/common/ad/sssd.conf

# Configuration for the System Security Services Daemon (SSSD)
[sssd]

# Syntax of the config file; always 2
config_file_version = 2

# Services that are started when sssd starts
services = nss, pam

# List of domains in the order they will be queried
domains = {{ pillar['ad_domain'] | upper }}

# Configuration for the AD domain
[domain/{{ pillar['ad_domain'] | upper }}]

# Use the Active Directory Provider
id_provider = ad

# Use Active Directory for access control
access_provider = ad

# Turn off sudo support in sssd - we're doing it directly in /etc/sudoers.d/
# and leaving this enabled results in spurious emails being sent to root
sudo_provider = none

# UNIX and Windows use different mechanisms to identify groups and users.
# UNIX uses integers for both; the challenge is to generate these consistently
# across all machines from the objectSID.
#
# Active Directory provides an objectSID for every user and group object in
# the directory. This objectSID can be broken up into components that represent
# the Active Directory domain identity and the relative identifier (RID) of the
# user or group object.
#
# The SSSD ID-mapping algorithm takes a range of available UIDs and divides it into
# equally-sized component sections - called "slices"-. Each slice represents
# the space available to an Active Directory domain.
#
# The default configuration results in configuring 10,000 slices, each capable
# of holding up to 200,000 IDs, starting from 10,001 and going up to
# 2,000,100,000. This should be sufficient for most deployments.
ldap_id_mapping = true

# Define some defaults for accounts that are not already on this box.
# We appear to need these settings as well as the PAM configuration.
fallback_homedir = /home/%d/%u
default_shell = /bin/bash
skel_dir = /etc/skel

/srv/salt/common/ad/pam_configs/ad

Name: AD user home management
Default: yes
Priority: 127

Session-Type: Additional
Session-Interactive-Only: yes
Session:
        required pam_mkhomedir.so skel=/etc/skel/ umask=0022

The AD configuration is more-or-less complete. There are still a couple of bits left to do:

  • Configuring NTP to point at the domain controller to get a consistent time;
  • Pushing the AD join script to the machine so that you can run it.

I’ll cover those in future posts.

2 thoughts on “AD for Debian with SaltStack – Part 3 – SSSD, PAM and sudo

  1. Hi Martin,

    I’m just trying to port your instructions from Debian to SLES15 and it seems to work fine so far. Thanks for your efforts!

    I stumbled on updating the file “nsswitch.conf” .
    It seems that ” – repl: ‘1 sss'” will replace the lines for passwd and group by “1 sss” which isn’t a valid entry in nsswitch.conf (AFAIK).
    Actually my knowledge of Salt is very poor so I don’t know if this “repl” statement is correct or how it should be corrected. Maybe you could give me some additional information about this task.

    Thanks in advance!

    Regards,
    Tobias.

    Like

    • The requirement is for /etc/nsswitch.conf to refer the correct lookups to sssd. I wrote this page: https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectorySssd which describes what the Salt configuration is trying to do.

      The key part is this:
      Line starts Should have sss? Example
      passwd: Yes passwd: compat sss
      group: Yes group: compat sss
      netgroup: Yes netgroup: nis sss
      sudoers: No sudoers: files

      Note that sudoers line contains sss on sssd installation; you will want to take this out to avoid spurious security emails being sent.

      I hope this resolves your issue. I wrote this post some time ago so the details are slightly hazy now!

      Like

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 )

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.