2

最近我们将我们的 Linux 服务器绑定到了一个 AD 域。我们现在可以进行简单的操作，如下：

  1. 使用 AD 帐户登录我们的 Linux 服务器（也可以通过 SSH）
  2. 使用 id 命令列出并识别我们的 AD 组
  3. 创建文件，获得这些文件的所有权和另一个简单的操作
  4. 在涉及我们的 AD 用户和组的 Linux 服务器上创建 ACL

但是，似乎我们的用户无法访问其主要组以外的组。

我们尝试过的步骤

假设名为 foo 的 AD 用户是“group_A@domain.dom”、“group_B@domain.dom”AD 组的成员，并且 group_A 被定义为主要组。我们预计用户 foo 将能够访问 group_A 或 group_B 拥有的文件，但我们发现用户 foo 无法访问分配给 group_B 拥有（或具有权限）的文件。

因此，我们的用户是很多广告组的成员，但只有主组是有效的，并且可以让我们的用户访问 Linux 服务器中的文件。这种现象似乎发生在我们所有的环境中

我们可以做些什么来让我们的 AD 用户通过他们所属的所有组获得访问权限，而不仅仅是他们的主要组？

技术信息

我们使用的是 Rhel7 Linux 服务器，我们使用领域工具将它加入到 windows 域中。我们没有给我们的用户一个 POSIX 属性，并且有一个自动 ID 映射

4

1 回答 1

0

嗯....用户尝试访问的某些文件似乎位于 NFSv4 共享上。

当使用带有 sys 身份验证挂载选项的 NFS 共享时，NFS 服务器“信任”前16 个组，而不是由域解析 [这是“16 个组”问题 - NFS 中的常见问题，因为该协议早在rfc5531中就出现了]。

因此，NFS 服务器将 16 个第一个用户的 gid 与分配给用户尝试访问的文件的 gid 进行比较。

但是，如果用户是具有大量嵌套 组的域用户，Linux 服务器并不总是以相同的顺序解析它们。因此，无法确保其中一些组是前 16 个用户组之一（因此适用于 NFS 服务器术语），除非它是用户的主要组！

绕过这个的方法：

  1. 将身份验证 NFS 方法更改为 Kerberos 之类的方法
  2. 关闭 Kerberos linux 客户端 [在我们的例子中为 sssd] 中的嵌套组支持，并确保使用用户的 1 组嵌套级别完成权限
  3. 在域级别为每个用户维护 unix 属性

我们所做的？

由于我们的 NFS 服务器是 ONTAP 虚拟服务器，我们可以关闭 16 个组的限制。但是，当您在 ONTAP 中执行此操作时，vserver 不再自动支持前 16 个组 - 它尝试通过名称服务（LDAP/本地 ONTAP 用户/组）解析所有组。

但是，netapp LDAP 客户端是“愚蠢的”——它不能做 sssd 所做的事情。因此，ONTAP LDAP 客户端（在nsswitch命令中定义）正在执行“纯”LDAP。当它尝试翻译组/用户时，它会尝试搜索为 Active Directory 中的用户/组分配的 LDAP Unix 属性。我已经向 NetApp 询问过这个问题……SSSD 客户端作为名称服务的开发不可用

我的建议？

您必须达到 Linux 服务器的 Unix LDAP 客户端和 NetApp VServer 以相同的逻辑运行的状态。

或者

通过 Pure LDAP 开启 Linux 客户端并为您需要的组维护 unix attrs

或者

为特定组创建本地 PASSWD ontap 文件

完毕

于 2021-07-06T06:41:20.900 回答