☰

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]: 백엔드 오프라인

가끔 오류가 다시 발생합니다.아니면 나중에라도사용자의 그룹이 다음과 같은지 확인하세요.이전 설정으로 돌아가기.

관련 정보