Skip to main content
NetApp Solutions
简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

其他NAS基础架构服务依赖关系(KDC、LDAP和DNS)

贡献者

使用适用于NAS共享的Google Cloud NetApp卷时、可能需要外部依赖关系才能正常运行。这些依赖关系在特定情况下起作用。下表显示了各种配置选项以及需要哪些依赖关系(如果有)。

Configuration 需要依赖关系

仅限NFSv3

仅限NFSv3 Kerberos

Windows Active Directory:* KDC * DNS * LDAP

仅限NFSv4.1

客户端ID映射配置(/etc/idmap.conf)

仅限NFSv4.1 Kerberos

  • 客户端ID映射配置(/etc/idmap.conf)

  • Windows Active Directory:KDC DNS LDAP

仅SMB

Active Directory:* KDC * DNS

多协议NAS (NFS和SMB)

  • 客户端ID映射配置(仅限NFSv4.1;/etc/idmap.conf)

  • Windows Active Directory:KDC DNS LDAP

计算机帐户对象的Kerberos keytab轮换/密码重置

对于SMB计算机帐户、Google Cloud NetApp卷会为SMB计算机帐户计划定期密码重置。这些密码重置会使用Kerberos加密进行、并按每第四个星期日的计划在晚上11点到凌晨1点之间随机运行。这些密码重置会更改Kerberos密钥版本、轮换存储在Google Cloud NetApp卷系统上的密钥选项卡、并有助于为在Google Cloud NetApp卷中运行的SMB服务器保持更高级别的安全性。计算机帐户密码是随机设置的、管理员不知道这些密码。

对于NFS Kerberos计算机帐户、只有在与KDC创建/交换新的keytab时、才会发生密码重置。目前、在Google Cloud NetApp卷中无法执行此操作。

用于LDAP和Kerberos的网络端口

使用LDAP和Kerberos时、您应确定这些服务正在使用的网络端口。您可以在中找到Google Cloud NetApp卷正在使用的端口的完整列表 "有关安全注意事项的Google Cloud NetApp Volumes文档"

LDAP

Google Cloud NetApp卷充当LDAP客户端、并使用标准LDAP搜索查询查找UNIX身份的用户和组。如果您要使用Google Cloud NetApp卷提供的标准默认用户之外的用户和组、则必须使用LDAP。如果您计划将NFS Kerberos与用户主体(如user1@domain.com)结合使用、也需要LDAP。目前、仅支持使用Microsoft Active Directory的LDAP。

要使用Active Directory作为UNIX LDAP服务器、您必须在要用于UNIX身份的用户和组上填充必要的UNIX属性。Google Cloud NetApp卷使用默认LDAP模式模板,该模板根据查询属性 "RFC-2307-bis"。因此、下表显示了为用户和组填充所需的最小Active Directory属性以及每个属性的用途。

有关在Active Directory中设置LDAP属性的详细信息、请参见 "管理双协议访问。"

属性 功能

UID*

指定UNIX用户名

uidNumber*

指定UNIX用户的数字ID

gidNumber*

指定UNIX用户的主组数字ID

objectclass*

指定正在使用的对象类型;Google Cloud NetApp卷要求在对象类列表中包含"user"(默认情况下、大多数Active Directory部署中都包含此对象)。

name

有关帐户的常规信息(真实姓名、电话号码等、也称为gecos)

unixUserPassword

无需设置此参数;不会在用于NAS身份验证的UNIX身份查找中使用。如果设置此选项、则会将配置的unixUserPassword值设置为纯文本。

unixHomeDirectory

定义用户从Linux客户端根据LDAP进行身份验证时UNIX主目录的路径。如果要使用LDAP for UNIX主目录功能、请设置此选项。

loginShell

定义用户根据LDAP进行身份验证时Linux客户端的bash/配置文件Shell的路径。

*表示要使Google Cloud NetApp卷正常运行、需要属性。其余属性仅供客户端使用。

属性 功能

CN*

指定UNIX组名称。使用Active Directory进行LDAP时、会在首次创建对象时设置此值、但可以稍后更改。此名称不能与其他对象相同。例如、如果名为user1的UNIX用户属于Linux客户端上名为user1的组、则Windows不允许两个具有相同CN属性的对象。要解决此问题、请将Windows用户重命名为一个唯一名称(例如user1-unUNIX);Google Cloud NetApp卷中的LDAP对UNIX用户名使用uid属性。

gidNumber*

指定UNIX组数字ID。

objectclass*

指定正在使用的对象类型;Google Cloud NetApp卷要求将组包含在对象类列表中(默认情况下、大多数Active Directory部署都包含此属性)。

memberUID

指定哪些UNIX用户是UNIX组的成员。对于Google Cloud NetApp卷中的Active Directory LDAP、此字段不是必需的。Google Cloud NetApp卷LDAP模式使用"成员"字段作为组成员资格。

成员*

组成员资格/二级UNIX组必需。此字段通过向Windows组添加Windows用户来填充。但是、如果Windows组未填充UNIX属性、则这些属性不会包含在UNIX用户的组成员资格列表中。任何需要在NFS中可用的组都必须填充此表中列出的所需UNIX组属性。

*表示要使Google Cloud NetApp卷正常运行、需要属性。其余属性仅供客户端使用。

LDAP绑定信息

要在LDAP中查询用户、Google Cloud NetApp卷必须绑定(登录)到LDAP服务。此登录具有只读权限、用于查询LDAP UNIX属性以查找目录。目前、LDAP绑定只能使用SMB计算机帐户。

您只能为实例启用LDAP NetApp Volumes-Performance、并将其用于NFSv3、NFSv4.1或双协议卷。要成功部署已启用LDAP的卷、必须在与Google Cloud NetApp卷所在的区域建立Active Directory连接。

启用LDAP后、在特定情况下会发生以下情况。

  • 如果Google Cloud NetApp卷项目仅使用NFS3或NFSv4.1、则会在Active Directory域控制器中创建新的计算机帐户、而Google Cloud NetApp卷中的LDAP客户端会使用计算机帐户凭据绑定到Active Directory。不会为NFS卷创建任何SMB共享,默认隐藏管理共享(请参阅一节""默认隐藏共享"")已删除共享ACL。

  • 如果在Google Cloud NetApp卷项目中使用双协议卷、则只会使用为SMB访问创建的单个计算机帐户将Google Cloud NetApp卷中的LDAP客户端绑定到Active Directory。不会创建其他计算机帐户。

  • 如果专用SMB卷是单独创建的(在启用具有LDAP的NFS卷之前或之后)、则用于LDAP绑定的计算机帐户将与SMB计算机帐户共享。

  • 如果还启用了NFS Kerberos、则会创建两个计算机帐户—一个用于SMB共享和/或LDAP绑定、一个用于NFS Kerberos身份验证。

LDAP查询

尽管LDAP绑定已加密、但LDAP查询仍会使用通用LDAP端口389以纯文本形式通过网线进行传递。目前无法在Google Cloud NetApp卷中更改此众所周知的端口。因此、有权在网络中嗅探数据包的用户可以查看用户和组名称、数字ID以及组成员资格。

但是、Google Cloud VM无法嗅探其他VM的单播流量。只有主动参与LDAP流量(即能够绑定)的VM才能看到LDAP服务器的流量。有关在Google Cloud NetApp卷中发现数据包的详细信息、请参见一节"《数据包嗅探/跟踪注意事项》。"

LDAP客户端配置默认值

默认情况下、如果在Google Cloud NetApp卷实例中启用了LDAP、则会使用特定配置详细信息创建LDAP客户端配置。在某些情况下、选项不适用于Google Cloud NetApp卷(不受支持)或不可配置。

LDAP客户端选项 功能 默认值 是否可以更改?

LDAP服务器列表

设置要用于查询的LDAP服务器名称或IP地址。这不适用于Google Cloud NetApp卷。而是使用Active Directory域定义LDAP服务器。

未设置

Active Directory域

设置用于LDAP查询的Active Directory域。Google Cloud NetApp卷利用DNS中LDAP的SRV记录查找域中的LDAP服务器。

设置为在Active Directory连接中指定的Active Directory域。

首选Active Directory服务器

设置用于LDAP的首选Active Directory服务器。Google Cloud NetApp卷不支持。而是使用Active Directory站点控制LDAP服务器选择。

未设置。

使用SMB服务器凭据绑定

使用SMB计算机帐户绑定到LDAP。目前、是Google Cloud NetApp卷中唯一受支持的LDAP绑定方法。

true

模式模板

用于LDAP查询的模式模板。

MS-AD-BIS

LDAP服务器端口

用于LDAP查询的端口号。Google Cloud NetApp卷当前仅使用标准LDAP端口389。目前不支持LDAPS/端口636。

389.

是否已启用LDAPS

控制是否对查询和绑定使用基于安全套接字层的LDAP (SSL)。目前Google Cloud NetApp卷不支持。

false

查询超时(秒)

查询超时。如果查询所用时间超过指定值、则查询将失败。

3.

最低绑定身份验证级别

支持的最低绑定级别。由于Google Cloud NetApp卷使用计算机帐户进行LDAP绑定、并且Active Directory默认不支持匿名绑定、因此此选项不起作用。

匿名

绑定 DN

使用简单绑定时用于绑定的用户/可分辨名称(DN)。Google Cloud NetApp卷使用计算机帐户进行LDAP绑定、目前不支持简单绑定身份验证。

未设置

基础DN

用于LDAP搜索的基础DN。

用于Active Directory连接的Windows域、采用DN格式(即DC=domain、DC=local)。

基本搜索范围

基础DN搜索的搜索范围。值可以包括base、onelevel或subtree。Google Cloud NetApp卷仅支持子树搜索。

子树

用户DN

定义LDAP查询的用户搜索开始位置的DN。目前Google Cloud NetApp卷不支持、因此所有用户搜索都从基础DN开始。

未设置

用户搜索范围

用户DN搜索的搜索范围。值可以包括base、onelevel或subtree。Google Cloud NetApp Volumes不支持设置用户搜索范围。

子树

组DN

定义为LDAP查询开始组搜索的DN。目前Google Cloud NetApp卷不支持、因此所有组搜索都从基础DN开始。

未设置

组搜索范围

组DN搜索的搜索范围。值可以包括base、onelevel或subtree。Google Cloud NetApp Volumes不支持设置组搜索范围。

子树

网络组DN

定义为LDAP查询启动网络组搜索的DN。目前Google Cloud NetApp卷不支持、因此所有网络组搜索都从基础DN开始。

未设置

网络组搜索范围

网络组DN搜索的搜索范围。值可以包括base、onelevel或subtree。Google Cloud NetApp卷不支持设置网络组搜索范围。

子树

使用基于LDAP的start_tls

利用Start TLS通过端口389建立基于证书的LDAP连接。目前Google Cloud NetApp卷不支持。

false

启用netgroup-by-host查找

启用按主机名查找网络组、而不是扩展网络组以列出所有成员。目前Google Cloud NetApp卷不支持。

false

按主机的网络组DN

定义在LDAP查询中按主机搜索网络组的起始DN。Google Cloud NetApp卷目前不支持按主机分组。

未设置

netgroup-by-host搜索范围

netgroup-by-host DN搜索的搜索范围。值可以包括base、onelevel或subtree。Google Cloud NetApp卷目前不支持按主机分组。

子树

客户端会话安全性

定义LDAP使用的会话安全级别(签名、签章或无)。如果Active Directory请求、NetApp Volume-Performance支持LDAP签名。NetApp Volume-SW不支持LDAP签名。对于这两种服务类型、目前不支持密封。

LDAP转介跟踪

使用多个LDAP服务器时、如果在第一个服务器中找不到条目、则转介跟踪功能允许客户端引用列表中的其他LDAP服务器。Google Cloud NetApp卷目前不支持此功能。

false

组成员资格筛选器

提供了一个自定义LDAP搜索筛选器、用于从LDAP服务器查找组成员资格。目前Google Cloud NetApp卷不支持。

未设置

使用LDAP进行非对称名称映射

默认情况下、Google Cloud NetApp卷会双向映射具有相同用户名的Windows用户和UNIX用户、而无需特殊配置。只要Google Cloud NetApp卷能够找到有效的UNIX用户(使用LDAP)、就会进行1:1名称映射。例如、如果使用的是Windows用户 johnsmith、则如果Google Cloud NetApp卷可以找到在LDAP中名为的UNIX用户 johnsmith、则该用户的名称映射将成功、由创建的所有文件/文件夹 `johnsmith`将显示正确的用户所有权、并且无论使用的是哪种NAS协议、所有受影响的ACL `johnsmith`都将受支持。这称为对称名称映射。

非对称名称映射是指Windows用户和UNIX用户身份不匹配的情况。例如,如果Windows用户 johnsmith`的UNIX身份为 `jsmith,则Google Cloud NetApp卷需要一种方式来了解这种变化。由于Google Cloud NetApp卷目前不支持创建静态名称映射规则、因此必须使用LDAP查找用户的身份以查找Windows和UNIX身份、以确保文件和文件夹的所有权以及预期权限均正确无误。

默认情况下、Google Cloud NetApp卷会在名称映射数据库实例的ns-switch中包含 LDAP、以便通过对非对称名称使用LDAP来提供名称映射功能、您只需修改某些用户/组属性、以反映Google Cloud NetApp卷查找的内容。

下表显示了为实现非对称名称映射功能、必须在LDAP中填充哪些属性。在大多数情况下、Active Directory已配置为执行此操作。

Google Cloud NetApp卷属性 功能 Google Cloud NetApp卷用于名称映射的值

Windows到UNIX对象类

指定要使用的对象类型。(即用户、组、posixAccount等)

必须包括用户(如果需要、可以包含多个其他值。)

Windows到UNIX属性

用于在创建时定义Windows用户名。Google Cloud NetApp Volumes将此功能用于从Windows到UNIX的查找。

此处无需更改;sAMAccountName与Windows登录名相同。

UID

定义UNIX用户名。

所需的UNIX用户名。

Google Cloud NetApp卷当前不在LDAP查找中使用域前缀、因此多个域LDAP环境无法在LDAP名称映射查找中正常运行。

以下示例显示了一个名为`unymmetric`、UNIX名为`unix-user`的用户、以及从SMB和NFS写入文件时的行为。

下图显示了LDAP属性在Windows服务器中的外观。

图中显示了输入/输出对话框或表示已写入内容

在NFS客户端中、您可以查询UNIX名称、但不能查询Windows名称:

# id unix-user
uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup)
# id asymmetric
id: asymmetric: no such user

从NFS写入文件时、如果为`unix-user`、则NFS客户端会生成以下结果:

sh-4.2$ pwd
/mnt/home/ntfssh-4.2$ touch unix-user-file
sh-4.2$ ls -la | grep unix-user
-rwx------  1 unix-user sharedgroup     0 Feb 28 12:37 unix-user-nfs
sh-4.2$ id
uid=1207(unix-user) gid=1220(sharedgroup) groups=1220(sharedgroup)

在Windows客户端中、您可以看到文件所有者已设置为正确的Windows用户:

PS C:\ > Get-Acl \\demo\home\ntfs\unix-user-nfs | select Owner
Owner
-----
NTAP\asymmetric

相反、Windows用户`非对称`从SMB客户端创建的文件将显示正确的UNIX所有者、如以下文本所示。

SMB:

PS Z:\ntfs> echo TEXT > asymmetric-user-smb.txt

NFS :

sh-4.2$ ls -la | grep asymmetric-user-smb.txt
-rwx------  1 unix-user         sharedgroup   14 Feb 28 12:43 asymmetric-user-smb.txt
sh-4.2$ cat asymmetric-user-smb.txt
TEXT

LDAP通道绑定

由于Windows Active Directory域控制器存在一个漏洞、 "Microsoft安全建议ADV190023" 更改DC允许LDAP绑定的方式。

对Google Cloud NetApp卷的影响与对任何LDAP客户端的影响相同。Google Cloud NetApp Volumes当前不支持渠道绑定。由于默认情况下、Google Cloud NetApp Volumes支持通过协商进行LDAP签名、因此LDAP通道绑定应该不会出现问题。如果在启用通道绑定的情况下绑定到LDAP时确实遇到问题、请按照ADV190023中的修复步骤操作、以允许从Google Cloud NetApp卷成功绑定LDAP。

DNS

Active Directory和Kerberos都依赖于DNS来进行主机名到IP/IP到主机名解析。DNS要求端口53处于打开状态。Google Cloud NetApp Volumes不会对DNS记录进行任何修改、目前也不支持在网络接口上使用 "动态DNS"

您可以配置Active Directory DNS以限制哪些服务器可以更新DNS记录。有关详细信息,请参见 "保护Windows DNS的安全"

请注意、Google项目中的资源默认使用Google Cloud DNS、而Google Cloud DNS未连接到Active Directory DNS。使用云DNS的客户端无法解析Google Cloud NetApp卷返回的UNC路径。加入Active Directory域的Windows客户端已配置为使用Active Directory DNS、并且可以解析此类UNC路径。

要将客户端加入Active Directory、必须将其DNS配置为使用Active Directory DNS。或者、您也可以配置云DNS以将请求转发到Active Directory DNS。请参见 "为什么我的客户端无法解析SMB NetBIOS名称?"有关详细信息 …​

备注 Google Cloud NetApp卷目前不支持DNSSEC、并且DNS查询以纯文本形式执行。

文件访问审核

目前不支持Google Cloud NetApp卷。

防病毒保护

您必须在客户端的Google Cloud NetApp卷中对NAS共享执行防病毒扫描。目前还没有与Google Cloud NetApp Volumes进行本机防病毒集成。