SSSD 新しいグループがユーザーに追加されませんでした。「tsig検証に失敗しました...更新に失敗しました：拒否されました」？

2024-6-4 • tag-icon

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]: バックエンドオフライン

時にはエラーが再び発生します。それとも後でユーザーのグループが次のようになっていることを確認してください。前の設定に戻る。

関連情報