其他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 |
|
仅SMB |
Active Directory:* KDC * DNS |
多协议NAS (NFS和SMB) |
|
计算机帐户对象的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进行本机防病毒集成。