VNX：升级支持 SMB2 安全通道通信的代码后DOMAIN_CONTROLLER_NOT_FOUND
Summary: 升级支持 SMB2 安全通道与 DC 通信的代码后DOMAIN_CONTROLLER_NOT_FOUND消息。（戴尔可纠正）
Symptoms
代码已升级到上面列出的版本之一。
升级到以下代码之一后，日志中开始显示错误消息，指示域控制器已关闭：
VNX2：
8.1.9.211
VNX1：
7.1.82.0
消息如下所示：
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Cause
上述代码全部添加到一项新功能中，该功能允许 NAS 服务器或数据移动器与 SMB2 中的域控制器进行通信。在此代码之前，域控制器通信全部在 SMB1 中处理（尽管客户端仍然可以在 SMB2/SMB3 中与我们通信）。
在更改为 SMB2 后，我们的命令不会全部序列化到域控制器。这会导致一些命令同时并行运行。
例如，尝试打开名为 lsarpc 的管道。
在此错误消息中，请务必记下我们尝试绑定到的服务：
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
从错误消息中，我们可以看到它正在尝试打开 LSA（以红色突出显示）。这就是问题所在。在收到来自 DC 的响应之前，我们尝试同时多次打开以 lsarpc 命名的管道。第一个请求成功，但后续请求失败。我们会看到指示STATUS_PIPE_NOT_AVAILABLE的故障消息，并在日志中记录DOMAIN_CONTROLLER_NOT_FOUND消息。
请务必注意，这些消息并不总是指示此问题。DOMAIN_CONTROLLER_NOT_FOUND错误可能有很多原因。
此特定事件的日志中可能有很多以下信息性消息：
2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened 2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
如果对问题是否与问题匹配有任何疑问，可以在数据包跟踪中进行确认。在跟踪中，我们会看到多个同时请求在收到对其中任何一个的响应之前打开 lsarpc，然后第一个请求成功，后续请求失败，当 DC 响应时STATUS_PIPE_NOT_AVAILABLE。
此问题往往主要发生在需要在域控制器上进行大量 SID 查找的系统上。如果环境中存在孤立的 SID，则往往会记录更多的此类错误。这是由于发送到 DC 的流量，每次访问 ACL 时，我们都必须向 DC 发送请求，以询问 SID 缓存中没有的任何 SID 的身份。孤立的 SID 从不位于 SID 缓存中，每次增加我们必须对名为 lsarpc 的管道执行的打开数量时，都会尝试查找孤立的 SID。
由于第一次打开尝试成功，这是一个无影响事件，可以忽略这些消息。
Resolution
永久修复：
工程部门已意识到这个问题，并正在努力在未来的代码版本中进行修复。这是一个无中断问题，在此期间可以安全地忽略。但是，如果您确实希望尝试减少或消除消息，可以使用一些解决方法。
解决方法 1：
有几种方法可以尝试阻止这些消息在日志中出现。由于 lsarpc 管道上的多个并发打开尝试会导致问题，因此减少消息的最简单方法是减少所需的 SID 查找量。
孤立的 SID 会导致这些过多的查找。可以修改以下参数，以强制查找查看 secmap 缓存中是否存在未知 sid，并应减少流向 DC 的流量：
[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v server_2 : name = acl.mappingErrorAction facility_name = cifs default_value = 8 current_value = 8 configured_value = 8 user_action = none change_effective = immediate range = (0,31) description = Define rules for an unknown SID/UID/GID mapping detailed_description Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID
这转换为以下信息：
Bit0 = 存储未知 sid。
Bit1 = 存储没有 UNIX 映射的 sid。
Bit2 = 启用调试跟踪。
Bit3 = 仅在缓存中查找（secmap 或 globalSid 缓存或每个连接 SID 缓存）
如果设置了位 0 和位 1（0x3 作为值），则允许孤立的 SID 存储在文件系统 ACL 上（默认情况下不提供）。建议将值从 0x3 更改为 0x11，这将打开位 0、1 和 3。这意味着存储没有 unix 映射的未知 SID，并且仅在 secmap 和全局 SID 缓存中查找。如果将其设置为 0x8 位或位 0 和 1 处于关闭状态的其他组合，则不允许存储孤立 SID，并且不应对此参数进行任何更改。
如果要修改参数，可以运行以下命令：
server_param server_2 -f cifs -m acl.mappingErrorAction -v 11
这可能会减少发生，但可能会也可能不会完全消除它们。
解决方法 2：
消除日志中的这些错误的可靠方法是将 DC 通信行为恢复到新代码之前的行为（这意味着我们仅与 SMB1 中的域控制器通信）。
如果您想要恢复到 SMB1 进行直流通信（旧 VNX 行为），请联系戴尔支持并参考此知识库文章。