DFS Namespace Resolution without netbios - Why does it work

Question

So, my problem is not that something does not work. But that it works, and I cannot figure out why.

Short version: I am able to access \\mydomain\MyDFSRoot even though netbios/LLMNR is off, and DNS-entry mydomain.mydomain.locale does not exist. I cannot fathom why.

Details

AD-Forest/Domain: MyDomain.locale
DFS-Namespace: MyDomain.locale/MyDFSRoot (v2)
Forest/Domain Level: 2008R2

Test computers:

DC1 (Domain Controller - WS2019)
SRV (DFS Namespace server - WS2019)
CLI (Client, Windows 10 1903) (There are no other computers in this network)

Config:

LLMNR - Off via GPO
Netbios Node-Type P-Node via GPO
NO WINS available nor configured
Netbios over TCP/IP disabled on network adapters
SMBv1 disabled via GPO (No Computer Browser-service is running)
DFS-Configuration set to use FQDN on both DC and DFSn-Server (but does not seem to matter)
DNS suffix search list is default (mydomain.locale)
CLI is separated in its own network (vswitch and routed to DC/SRV), this to avoid any broadcast packets
No external traffic from the network nor any external DNS configuration

Observations:

WORKS: All DFSN-paths (\mydomain(sysvol|netlogon|mydfsroot)
NOT WORKS: A shared folder on the DC \mydomain\dcsharedfolder
DELAY: If I boot the Client disconnected from the network, log on, enable networking and test.. it might take seconds/minutes before it works.
LLMNR/Netbios/BROWSER is OFF: I have captured all traffic, there is no trace of these protocols
ipconfig /flushdns, dfsutil cache * flush etc is heavily used without seeming to have any effect

Update: Possible Answer It seems I have located the network packet that will trigger the shortname to work. At some point a packet of type SMB2 will be sent Request [FSCTL_DFS_GET_REFERRALS], FILE: (Note there is no file path present)(Wireshark filter smb2.ioctl.function == 0x00060194). In turn I get the following response from the domain controller:

            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

Now the Microsoft Article "How DFS Works" has the following quote:

"Any UNC request on the client comes to DFS first before any of the network redirectors. DFS checks its domain cache to determine whether the name is a domain name"

However, it also states that the MUP Cache must know about the path beforehand. This might explain why it initially does not work, but works 'if I wait a bit'. Checking the DFS domain cache before it starts working:

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

And after it starts working:

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

The entry with [+] in front should be a referral, while [*] is "received from the workstation service". In this scenario this would imply that this works now because I have gotten a referral for the path, which is probably because something else (GPO I am thinking) access the DFS-root.

EDIT2: I checked the PID of the process that sent the query and it was the workstation service.

`DNS-entry mydomain.mydomain.locale does not exist`. And why would that be? AD doesn't work if there is not a DNS entry for the domain/forest name. `DNS suffix search list is default (mydomain.locale)`. Could be the reason. All you need to do is perform a packet capture. — Greg Askew, Oct 04 '19 at 14:47
You say that you captured traffic and there's no trace of NetBIOS or LLMNR... but there has to be something in the capture. What do you see in the capture? — joeqwerty, Oct 04 '19 at 14:50
@GregAskew It seems to be the common way to work around this such as seen in post https://serverfault.com/questions/886756/dfs-namespaces-dns-and-netbios-name-resolution . Because mydomain.modomain.locale would make \\mydomain 'work' with DNS (using DNS suffix search list) — Zerqent, Oct 07 '19 at 05:41
@joeqwerty Yeah I know - but the trace quickly becomes larger so there might be a number of places where this happens. Theories for today: Either the client at some point queries for the DFSn-information in LDAP - or it talks to \\mydomain.locale and is given that information somehow. — Zerqent, Oct 07 '19 at 05:42

score 0 · Accepted Answer · answered Jan 10 '20 at 09:45

Seems i figured this out (look at question for long answer). Basically:

DFS uses short names without using Netbios
If you visit a DFSn namespace it will provide you with aliases for it - including a short version.
UNC tries DFS before other providers (e.g. normal name resolution)

DFS Namespace Resolution without netbios - Why does it work

1 Answers1