1

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:

  1. DC1 (Domain Controller - WS2019)
  2. SRV (DFS Namespace server - WS2019)
  3. 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.

  • 2
    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 4 '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 4 '19 at 14:50
  • "mydomain.mydomain.locale" is NOT the forest name. – Semicolon Oct 4 '19 at 18:31
  • @GregAskew It seems to be the common way to work around this such as seen in post serverfault.com/questions/886756/… . Because mydomain.modomain.locale would make \\mydomain 'work' with DNS (using DNS suffix search list) – Zerqent Oct 7 '19 at 5: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 7 '19 at 5:42
0

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)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.