☰

不使用 netbios 的 DFS 命名空间解析 - 它为何有效

tag-icon • tag-icon windows active-directory dfs netbios
不使用 netbios 的 DFS 命名空间解析 - 它为何有效

所以，我的问题不是某样东西不起作用。而是它起作用了，而我却不知道为什么。

简洁版本： 即使 netbios/LLMNR 已关闭，我仍可以访问 \\mydomain\MyDFSRoot，并且 DNS 条目 mydomain.mydomain.locale 不存在。我无法理解为什么。

细节

  • AD 林/域：MyDomain.locale
  • DFS 命名空间：MyDomain.locale/MyDFSRoot (v2)
  • 林/域级别：2008R2

测试计算机：

  1. DC1（域控制器-WS2019）
  2. SRV（DFS 命名空间服务器 - WS2019）
  3. CLI（客户端，Windows 10 1903）（此网络中没有其他计算机）

配置：

  • LLMNR - 通过 GPO 关闭
  • 通过 GPO 的 Netbios 节点类型 P 节点
  • 未提供或配置 WINS
  • 网络适​​配器上已禁用 TCP/IP 上的 Netbios
  • SMBv1 通过 GPO 禁用（没有计算机浏览器服务正在运行）
  • DFS 配置设置为在 DC 和 DFSn 服务器上都使用 FQDN（但似乎并不重要）
  • DNS 后缀搜索列表为默认 (mydomain.locale)
  • CLI 在其自己的网络中分离（vswitch 并路由到 DC/SRV），这是为了避免任何广播数据包
  • 没有来自网络的外部流量，也没有任何外部 DNS 配置

观察结果：

  • 工作：所有 DFSN 路径 (\mydomain(sysvol|netlogon|mydfsroot)
  • 不起作用：DC \mydomain\dcsharedfolder 上的共享文件夹
  • 延迟：如果我启动与网络断开的客户端，登录、启用网络并测试..它可能需要几秒钟/几分钟才能正常工作。
  • LLMNR/Netbios/BROWSER 已关闭：我已捕获所有流量，但没有这些协议的踪迹
  • ipconfig /flushdns、dfsutil cache * flush 等被大量使用，但似乎没有任何效果

更新：可能的答案 看来我已经找到了可以触发短名称工作的网络数据包。在某个时候，SMB2将发送一个类型的数据包Request [FSCTL_DFS_GET_REFERRALS], FILE:（请注意，不存在文件路径）（Wireshark 过滤器smb2.ioctl.function == 0x00060194）。反过来，我从域控制器收到以下响应：

            Referrals
                Referral
                    Version: 3
                    Size: 18
                    Server Type: Non-root targets returned (0)
                    Flags: 0x0002, NameListReferral
                    TTL: 600
                    Domain Offset: 36
                    Number of Expanded Names: 0
                    Expanded Names Offset: 0
                    Domain Name: \MYDOMAIN
                Referral
                    Version: 3
                    Size: 18
                    Server Type: Non-root targets returned (0)
                    Flags: 0x0002, NameListReferral
                    TTL: 600
                    Domain Offset: 34
                    Number of Expanded Names: 0
                    Expanded Names Offset: 0
                    Domain Name: \MYDOMAIN.LOCALE

现在微软文章“DFS 的工作原理”有以下引述：

“客户端上的任何 UNC 请求都会先到达 DFS，然后再到达任何网络重定向器。DFS 检查其域缓存以确定该名称是否为域名”

但是，它还指出 MUP 缓存必须事先知道路径。这也许可以解释为什么它最初不起作用，但“如果我等一会儿”就会起作用。在开始工作之前检查 DFS 域缓存：

[*][]
[*][MYDOMAIN]
[*][mydomain.locale]
[+][mydomain.locale]
        [+TESTDC.pertra.locale]

开始工作后：

[*][TESTDC.mydomain.locale]
[*][MYDOMAIN]
[*][mydomain.locale]
[+][mydomain]
        [+TESTDC] AccessStatus: 0
[+][mydomain.locale]
        [+TESTDC.mydomain.locale]

前面带有 [+] 的条目应该是引用，而 [*] 是“从工作站服务接收的”。在这种情况下，这意味着现在它可以工作了，因为我已经获得了该路径的引用，这可能是因为其他东西（我认为是 GPO）访问了 DFS 根。

编辑2：我检查了发送查询的进程的 PID，它是工作站服务。

答案1

看来我已经搞清楚了（看问题以获得长答案）。基本上：

  • DFS 使用短名称而不使用 Netbios
  • 如果您访问 DFSn 命名空间，它将为您提供它的别名 - 包括一个简短版本。
  • UNC 在其他提供商之前尝试 DFS（例如正常名称解析）

相关内容