Announcement

Collapse
No announcement yet.

Incorrect AD site when browsing to Domain

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Incorrect AD site when browsing to Domain

    Hi all,

    If I browse to \\mydomainname using Windows Explorer am I correct in thinking that I should get referred to a Domain Controller in my current AD site? Currently I am not, and I'm wondering if there is a problem. I definitely authenticate with a DC in the correct AD site, but when browsing to the domain I mostly, but not always, get pointed at a DC in a different AD site. Can anyone explain this please?

    Thanks.

  • #2
    Re: Incorrect AD site when browsing to Domain

    Initially I was going to agree with you and say yes it should, but thinking about it I don't see why it would. At the end of the day what you are doing there is just a simple DNS\NetBIOS lookup for "mydomain" and then connecting to whatever IP address gets returned from that. As far as I know Windows won't do anything different to if you were to try to access any PC on your network (e.g \\somePC). Its not like when you authenticate and Windows goes through a specific process of trying to find the best DC - in this case where you are just going to \\mydomain I don't think Windows checks to see if its a domain name you are trying to access and acts differently.

    So basically, I think the DC you actually get will just be the first one that gets returned from the DNS/NetBIOS name lookup. Not sure if there is any way to control that, as it seems to be different each time when I just tested it (if you do an ipconfig /flushdns on the PC you are testing it on in between each lookup) so it seems like there is no explicitly set order.
    Software for IT Pros that I've written: http://www.cjwdev.co.uk/Software.html

    My blog: http://cjwdev.wordpress.com

    Comment


    • #3
      Re: Incorrect AD site when browsing to Domain

      Try comparing \\mydomain with \\mydomain.corp (or whatever the fqdn is). I think the latter does use SRV records, which are required to resolve sites.

      Alternatively look at preventing NETBios packets traversing your WAN, although this may have "unexpected" side effects
      Tom Jones
      MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
      PhD, MSc, FIAP, MIITT
      IT Trainer / Consultant
      Ossian Ltd
      Scotland

      ** Remember to give credit where credit is due and leave reputation points where appropriate **

      Comment


      • #4
        Re: Incorrect AD site when browsing to Domain

        Yeah I would definitely recommend using the FQDN of your domain (e.g mydomain.local) wherever you can instead of the NetBIOS name (e.g MYDOMAIN) but I think either way it won't do anything special for a domain name compared to any other host name you try to resolve. I'm not sure that SRV records come into it - they are used for locating specific services (such as LDAP and Kerberos services) so I don't see why just trying to browse the UNC path of \\mydomain.local would lookup any such services (ignoring the authentication that might need to happen for you to access that UNC path), as far as I can see its just a straight forward A record lookup.
        Software for IT Pros that I've written: http://www.cjwdev.co.uk/Software.html

        My blog: http://cjwdev.wordpress.com

        Comment


        • #5
          Re: Incorrect AD site when browsing to Domain

          Just did a test that proves it only does an A record lookup, not an SRV record lookup. I did an ipconfig /flushdns and then started a Wireshark trace for any DNS traffic and went to Start -> Run -> \\ourdomain.com and the only DNS traffic I saw was my machine doing an A record lookup for ourdomain.com and then the response that you can see in the attached screenshot, which shows our DNS server returning a list of all of our DCs.
          Attached Files
          Software for IT Pros that I've written: http://www.cjwdev.co.uk/Software.html

          My blog: http://cjwdev.wordpress.com

          Comment

          Working...
          X