☰

服务器：使用 Active Directory 组进行 Sudo 失败，除非 /etc/sudoers 中的文件名与 AD 组的名称匹配

tag-icon • tag-icon active-directory kerberos sssd
服务器：使用 Active Directory 组进行 Sudo 失败，除非 /etc/sudoers 中的文件名与 AD 组的名称匹配

我所在的组织拥有许多 Linux 服务器，我们希望开始使用 Active Directory 进行身份验证。我设置了一个概念验证服务器，在该服务器上使用 SSSD 和 Kerberos 通过 Active Directory 进行身份验证。目前，我已将其设置为只有特定组（我们称之为 A 组）的用户才能登录服务器，并且工作正常。接下来，我开始让另一个组（B 组）的用户自动拥有 sudo 权限。以下是 Active Directory 中组织单位的结构：

A组

A组结构

B组

B组结构

我可以作为 Active Directory 用户成功登录，并且我已将 sssd.conf 包含在下面：

[sssd]
services = nss, pam
config_file_version = 2
domains = <organization>.LOCAL

[domain/<organization>.LOCAL]
id_provider = ad
access_provider = ad

# Use this if users are being logged in at /.
# This example specifies /home/DOMAIN-FQDN/user as /root.  Use with pam_mkhomedir.so
override_homedir = /home/%d/%u

# makes all users use bash as the default shell
override_shell = /bin/bash

# only allows users from the following groups to log in
ad_access_filter = (|(memberOf=cn=group-A,ou=Groups,ou=department,dc=organization,dc=local))

为了允许 group-B 的所有成员 sudo 权限，我创建了一个名为 group-B-admin-group 的文件，其中/etc/sudoers.d包含以下内容：

%group-B    ALL=(ALL)   ALL

此时，即使对于 B 组的用户，我也无法使用 sudo。执行时sudo su会立即要求输入密码，然后报告该用户不在 sudoers 文件中。执行sudo touch this、sudo cat、sudo vim和其他此类命令需要我等待大约 60 秒才能询问我的密码。输入密码后，sudo 报告我不在 sudoers 文件中。此时，我将文件重命名/etc/sudoers.d/group-B-admin-group为/etc/sudoers.d/group-B，突然一切正常。 B 组用户会立即收到输入密码的提示，然后以提升的权限运行该程序。

我的问题是这样的：我认为该文件的名称没有实际意义（无论如何，您可以将多个用户/组的权限放在一个文件中。）我的配置的一部分是否要求组和文件的名称相同？我只是想了解为什么会这样

相关内容