0

After adding a user to a group in Active Directory and looking for that group to appear with the user on a linux server linked to AD via SSSD, noticing that the group is not added to the user (even after restarting the sssd service).

Checking the SSSD daemon status, I see...

[root@airflowetl ~]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-01-21 15:54:14 HST; 9min ago
 Main PID: 87108 (sssd)
   CGroup: /system.slice/sssd.service
           ├─87108 /usr/sbin/sssd -i --logger=files
           ├─87111 /usr/libexec/sssd/sssd_be --domain co.local --uid 0 --gid 0 --logger=files
           ├─87112 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─87113 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 1
Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 1
Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 1
Jan 21 15:54:14 airflowetl.co.local sssd_be[87111]: GSSAPI client step 2
Jan 21 15:54:14 airflowetl.co.local systemd[1]: Started System Security Services Daemon.
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: ; TSIG error with server: tsig verify failure
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: update failed: REFUSED
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: ; TSIG error with server: tsig verify failure
Jan 21 15:54:15 airflowetl.co.local sssd[87108]: update failed: REFUSED
Jan 21 16:00:40 airflowetl.co.local sssd[be[co.local]][87111]: Warning: user would have been denie....
Hint: Some lines were ellipsized, use -l to show in full.

I'm guessing the

update failed: REFUSED

part is the problem here.

For further reference, the server's /etc/sssd/sssd.conf file looks like...

[root@airflowetl ~]# cat /etc/sssd/sssd.conf

[sssd]
domains = co.local
config_file_version = 2
services = nss, pam

[domain/co.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local

Some OS info:

[root@airflowetl ~]# lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.4.1708 (Core)
Release:        7.4.1708
Codename:       Core

Note that we recently changed our primary DNS server and the /etc/resolv.conf file does reflect these changes, but I suspect that this is very related.

Does anyone with more experience with SSSD have any debugging tips or know what could be going wrong here?


UPDATE:

after checking a server where the DNS was not updated (rather the server is using the secondary DNS), when initially checking sssd status I see

[root@hwdatalake datalake]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-01-22 12:55:22 HST; 21h ago
 Main PID: 95837 (sssd)
   CGroup: /system.slice/sssd.service
           ├─95837 /usr/sbin/sssd -i --logger=files
           ├─95838 /usr/libexec/sssd/sssd_be --domain co.local --uid 0 --gid 0 --logger=files
           ├─95839 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─95840 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jan 22 12:55:17 hwdatalake.co.local systemd[1]: Starting System Security Services Daemon...
Jan 22 12:55:17 hwdatalake.co.local sssd[95837]: Starting up
Jan 22 12:55:17 hwdatalake.co.local sssd[be[co.local]][95838]: Starting up
Jan 22 12:55:22 hwdatalake.co.local sssd[pam][95840]: Starting up
Jan 22 12:55:22 hwdatalake.co.local sssd[nss][95839]: Starting up
Jan 22 12:55:22 hwdatalake.co.local systemd[1]: Started System Security Services Daemon.
Jan 22 12:56:50 hwdatalake.co.local sssd[be[co.local]][95838]: Backend is offline

then after restarting the service, see

[root@hwdatalake datalake]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2020-01-23 10:19:05 HST; 15s ago
 Main PID: 98653 (sssd)
   CGroup: /system.slice/sssd.service
           ├─98653 /usr/sbin/sssd -i --logger=files
           ├─98654 /usr/libexec/sssd/sssd_be --domain co.local --uid 0 --gid 0 --logger=files
           ├─98655 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─98656 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Jan 23 10:18:54 hwdatalake.co.local systemd[1]: Starting System Security Services Daemon...
Jan 23 10:18:54 hwdatalake.co.local sssd[98653]: Starting up
Jan 23 10:18:54 hwdatalake.co.local sssd[be[co.local]][98654]: Starting up
Jan 23 10:19:05 hwdatalake.co.local sssd[nss][98655]: Starting up
Jan 23 10:19:05 hwdatalake.co.local sssd[pam][98656]: Starting up
Jan 23 10:19:05 hwdatalake.co.local systemd[1]: Started System Security Services Daemon.

and checking the groups for a given user shows the updated groups being correctly associated with the user. Yet even then, after some time, when checking again I see that the

Jan 23 10:20:33 hwdatalake.co.local sssd[be[co.local]][98654]: Backend is offline

error is back and at some time even later checking the groups for the user is back to the old settings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.