沒有 netbios 的 DFS 命名空間解析 - 為什麼它有效

所以，我的問題不在於某些東西不起作用。但它有效，我不知道為什麼。

簡短版本： 即使 netbios/LLMNR 已關閉，並且 DNS 條目 mydomain.mydomain.locale 不存在，我也能夠訪問 \mydomain\MyDFSRoot。我無法理解為什麼。

細節

• 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
• 通過 GPO 禁用 SMBv1（沒有執行電腦瀏覽器服務）
• 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 etc 被大量使用，似乎沒有任何效果

更新：可能的答案 似乎我已經找到了將觸發短名稱工作的網路數據包。在某些時候，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

現在 Microsoft 文章“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-root。 EDIT2：我檢查了發送查詢的程序的 PID，它是工作站服務。

似乎我想通了（看問題的長答案）。基本上：

• DFS 使用短名稱而不使用 Netbios
• 如果你訪問一個 DFSn 命名空間，它會為你提供它的別名——包括一個簡短的版本。
• UNC 在其他提供者之前嘗試 DFS（例如，正常的名稱解析）

引用自：https://serverfault.com/questions/986791