将用户添加到 Active Directory 中的组并在通过 SSSD 链接到 AD 的 Linux 服务器上查找该组与用户一起出现后，注意到该组没有添加到用户（即使在重新启动服务后sssd）。
检查 SSSD 守护进程状态，我看到...
[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.
我猜
更新失败：拒绝
部分是这里的问题。
为了进一步参考，服务器的/etc/sssd/sssd.conf文件看起来像......
[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
一些操作系统信息：
[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
请注意，我们最近更改了主 DNS 服务器，并且该/etc/resolv.conf文件确实反映了这些更改，但我怀疑这是非常相关的。
有更多 SSSD 经验的人有任何调试技巧或知道这里可能出了什么问题吗？
更新：
检查 DNS 未更新的服务器（而不是服务器正在使用辅助 DNS）后，在最初检查 sssd 状态时，我看到
[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
然后重启服务后，看到
[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.
检查给定用户的组显示更新的组与该用户正确关联。但即便如此，过了一段时间，当再次检查时，我发现
1 月 23 日 10:20:33 hwdatalake.co.local sssd[be[co.local]][98654]：后端离线
错误有时又回来了甚至更晚检查用户的组是回到旧设置。