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.
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.
LikeLike
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!
LikeLike