☰

SSSD 新组未添加到用户，“tsig 验证失败...更新失败：拒绝”？

tag-icon • tag-icon active-directory sssd
SSSD 新组未添加到用户，“tsig 验证失败...更新失败：拒绝”？

将用户添加到 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]：后端离线

错误有时又回来了甚至更晚检查用户的组是回到旧设置。

相关内容