Announcement

Collapse
No announcement yet.

Managing off-site machines with only a corporate DC

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

  • Managing off-site machines with only a corporate DC

    Hello friends,

    I am managing a client who has one corporate office with a DC, and about 20 locations throughout the state with one computer at each location. We need to be able to properly manage these 20 machines through domain policies, so what we've done is as follows:

    Each location has a VPN back to corporate. Each machine has been joined to the domain. Each machine's DNS points to the DC back at corporate (over the VPN). The issue we are having is when the VPN fails or when the corporate office internet goes out, none of the remote locations can access the internet because they only have the DNS of the DC over the VPN. How do we allow the remote machines to use their local router (or OpenDNS) as their DNS, yet still remain connected to the DC at corporate so that we can keep them in sync and apply policies, and ensure they have uninterrupted DNS?

    I was thinking along the lines of a corporate entity (let's say United Airlines) that has laptops and executives traveling all over. The laptop is joined to the domain, which I suppose means that DNS needs to point to a DC, but that can't be the case because when they are home they would not get name resolution. And if the answer is that you join the machines to the domain at corporate and then let the machine roam with whatever DNS it picks up, how do you ensure that the machine doesn't tombstone, lose the trust relationship with the domain, and cached credentials don't run out?

    I appreciate the time you take to answer my question.

    Thanks!

  • #2
    Re: Managing off-site machines with only a corporate DC

    How about putting the local router as a secondary dns server?
    (see http://serverfault.com/questions/842...esolving-names for a discussion of which server gets used)

    Note there is no requirement to use a DC for DNS once the computer has been joined to the domain, so normally a laptop would pick up an IP from a local DHCP server (domain if in HQ, something else in a hotel) with the appropriate local DNS server address
    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


    • #3
      Re: Managing off-site machines with only a corporate DC

      Originally posted by Ossian View Post
      How about putting the local router as a secondary dns server?
      (see http://serverfault.com/questions/842...esolving-names for a discussion of which server gets used)
      Yes, that's definitely a possibility I was thinking of. However, onto my next comment...

      Originally posted by Ossian View Post
      Note there is no requirement to use a DC for DNS once the computer has been joined to the domain, so normally a laptop would pick up an IP from a local DHCP server (domain if in HQ, something else in a hotel) with the appropriate local DNS server address
      I have actually never heard this before, and I've been taught quite the opposite. I have been living with the impression that if a domain connected machine has its DNS set to non AD DC's, then it can never talk to the DC again, thus removing the ability for GPO updates to happen, password updates, etc. If my machine is joined to domain.local, and then uses 8.8.8.8 as the DNS afterwards, it will never be able to talk to domain.local again, even if I have a VPN back to my corporate office, because 8.8.8.8 has no idea what domain.local is.

      Comment


      • #4
        Re: Managing off-site machines with only a corporate DC

        Originally posted by kingbear2 View Post
        I have actually never heard this before, and I've been taught quite the opposite. I have been living with the impression that if a domain connected machine has its DNS set to non AD DC's, then it can never talk to the DC again, thus removing the ability for GPO updates to happen, password updates, etc. If my machine is joined to domain.local, and then uses 8.8.8.8 as the DNS afterwards, it will never be able to talk to domain.local again, even if I have a VPN back to my corporate office, because 8.8.8.8 has no idea what domain.local is.
        Sorry, but you have been taught a load of fecal matter
        Within the corporate LAN, yes, you should use AD DNS servers for all the reasons you mention, but away from the LAN there is no requirement,

        If you use a VPN, you will get a corporate IP address (usually via DHCP) which will include the AD DNS servers so GPOs etc can occur over the VPN

        I am typing this on a domain joined PC, in a hotel, on an IP address supplied by the hotel WiFi, and will return to base tomorrow, connect to the LAN, get a different IP address and get my policies, patches and all without problems. Next week I will do the same.
        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


        • #5
          Re: Managing off-site machines with only a corporate DC

          Well, I understand the concept that a machine that is constantly brought back to corporate should just get DHCP all the time since when the machine is at corporate, it connects to the local DC. How about when a machine is permanently off site, however connected through a VPN to corporate, but you don't want every DNS query to go over the VPN - which is my scenario. How would you handle that to make sure policies get applied and computers aren't tombstoning, yet still resolving IP's through regular public DNS?

          Comment


          • #6
            Re: Managing off-site machines with only a corporate DC

            Why would it be a problem if all DNS traffic went through the VPN? The packets are tiny and the DNS cache on the clients will prevent them from sending unnecessary requests.

            If this is really an issue, get a VPN router capable of zone-based DNS redirection, like the ZyWall USG series, and use that as a gateway on the remote site:
            • Have the remote site clients use the router as a DNS server (the router's built-in DHCP server can provide the parameters)
            • Set up a client/IPsec VPN between the router and the corporate network
            • Create two DNS forwarding rules: One forwarding requests for "ad.dns.name" (substitute the actual AD DNS zone name) to an internal DNS server, and another forwarding everything else to the ISP's DNS server(s)

            Comment


            • #7
              Re: Managing off-site machines with only a corporate DC

              Originally posted by Ser Olmy View Post
              Why would it be a problem if all DNS traffic went through the VPN? The packets are tiny and the DNS cache on the clients will prevent them from sending unnecessary requests.
              Right, but then if corporate internet is down, they lose all internet, unless I set the secondary DNS as 8.8.8.8 or OpenDNS.

              If this is really an issue, get a VPN router capable of zone-based DNS redirection, like the ZyWall USG series, and use that as a gateway on the remote site:
              • Have the remote site clients use the router as a DNS server (the router's built-in DHCP server can provide the parameters)
              • Set up a client/IPsec VPN between the router and the corporate network
              • Create two DNS forwarding rules: One forwarding requests for "ad.dns.name" (substitute the actual AD DNS zone name) to an internal DNS server, and another forwarding everything else to the ISP's DNS server(s)
              This is interesting. We have meraki's in there so I will contact them and see if it's possible. I don't suppose there is any way of doing this from the hosts file, is there?

              Comment


              • #8
                Re: Managing off-site machines with only a corporate DC

                Originally posted by kingbear2 View Post
                Right, but then if corporate internet is down, they lose all internet, unless I set the secondary DNS as 8.8.8.8 or OpenDNS.
                And if you specify a public secondary DNS server, the clients will keep using it even after the VPN comes back up, and won't be able to resolve names on the corporate network until they either reboot or disconnect/reconnect to reset their DNS settings. Not recommended at all.
                Originally posted by kingbear2 View Post
                This is interesting. We have meraki's in there so I will contact them and see if it's possible.
                The feature you're looking for, is called 'conditional forwarding'. Most DNS servers are capable of this, including the caching DNS servers found in many routers. The question is whether or not your router has a proxy DNS feature, and if so, if the manufacturer has included settings related to conditional forwarding in the management GUI.
                Originally posted by kingbear2 View Post
                I don't suppose there is any way of doing this from the hosts file, is there?
                Nope. The hosts file can contain static A record entries, but not directives related to DNS servers.

                Comment


                • #9
                  Re: Managing off-site machines with only a corporate DC

                  How would you handle that to make sure policies get applied and computers aren't tombstoning, yet still resolving IP's through regular public DNS?
                  If I could find the person that started this myth, I would cheerfully flog them to death with a network cable.

                  The only things in AD that tombstone are DCs, when they do not successfully replicate for a period of time. IIRC it's 30 days, but it's configurable. Normal PCs/laptops/member servers do NOT tombstone/drop off the domain or whatever else you want to call it because they haven't contacted a DC for a period of time.
                  BSc, MCSA: Server 2008, MCSE, MCSA: Messaging, MCTS
                  sigpic
                  Cruachan's Blog

                  Comment


                  • #10
                    Re: Managing off-site machines with only a corporate DC

                    Originally posted by cruachan View Post
                    Normal PCs/laptops/member servers do NOT tombstone/drop off the domain or whatever else you want to call it because they haven't contacted a DC for a period of time.
                    The computer account object of a PC may not get tombstoned, but the password will expire, causing the computer to effectively drop out of the domain.

                    In that scenario, the computer account object still very much exists in AD, and the PC will appear to be a member of the domain, but the security logs on both the DC and the PC fills up with authentication errors and users will no longer be able to log in using domain accounts (unless the PC is disconnected from the network and locally cached credentials are available for the account in question).

                    Comment


                    • #11
                      Re: Managing off-site machines with only a corporate DC

                      Originally posted by Ser Olmy View Post
                      The computer account object of a PC may not get tombstoned, but the password will expire, causing the computer to effectively drop out of the domain.

                      In that scenario, the computer account object still very much exists in AD, and the PC will appear to be a member of the domain, but the security logs on both the DC and the PC fills up with authentication errors and users will no longer be able to log in using domain accounts (unless the PC is disconnected from the network and locally cached credentials are available for the account in question).
                      This is not correct, as the password change for the machine account is initiated from the client side (only when connected to the network, so no changes if it can't contact AD) and not the AD side.

                      http://blogs.technet.com/b/askds/arc.../15/test2.aspx
                      BSc, MCSA: Server 2008, MCSE, MCSA: Messaging, MCTS
                      sigpic
                      Cruachan's Blog

                      Comment


                      • #12
                        Re: Managing off-site machines with only a corporate DC

                        Originally posted by cruachan View Post
                        This is not correct, as the password change for the machine account is initiated from the client side (only when connected to the network, so no changes if it can't contact AD) and not the AD side.

                        http://blogs.technet.com/b/askds/arc.../15/test2.aspx
                        This has nothing to do with how often a password change is initiated by a client, it has to do with how long it takes for a computer account password to expire when the client fails to update it. That's controlled by an AD setting, and assuming the defaults apply, it's enough to keep a PC disconnected for between 4-8 weeks (depending on when the password was last changed) to trigger this condition.

                        That's why the Internet is littered with posts about computers (apparently) losing their connection to an AD domain. If you've operated AD networks and have never experienced this, I believe you're in a relatively small (and lucky) minority.

                        For reasons I haven't bothered to research in any detail, Windows 7 systems are much more likely to get out of sync than previous incarnations of Windows. I (and many others) have even seen desktop PCs with a wired network connection fail to update their computer account passwords in a timely fashion.

                        Edit: I see that the article in the link actually says that computer account passwords never expire. That is not correct. OK, technically, the computer account password doesn't expire as such, and it is indeed not subject to any of the GPO password settings affecting user accounts, but if a computer account is unused for an extended period of time, the trust relationship expires and the only way to fix it is to, well, reset the account password.
                        Last edited by Ser Olmy; 25th April 2015, 02:34.

                        Comment


                        • #13
                          Re: Managing off-site machines with only a corporate DC

                          I've seen the trust relationship error more times than I can count, but I wholly dispute that last Microsoft blog posting suggesting that AD account password expiration is the cause of it. As I understand it, the password doesn't expire, but changes to "must change password at next logon" much like the check box we all use when resetting a user password. If it didn't do this, then the trust relationship error would be far more prevalent than it is.

                          In the NT days road warriors (as they were called back then) had very little access to the internet whilst travelling. At best it would be dial-up, and in those days it was a 7 day expiration by default. It was changed to 30 days by the time of XP/Server 2003 but the trust relationship failed error really took off with Vista and given that Vista was a colossal failure it's Windows 7 that everyone associates it with. I suspect, though can't get anyone at MPS to confirm, that this issue is caused by newer clients in an old AD domain (E.g. 2003 DCs with Vista or 7 clients) and sometimes the secure channel to the DC gets the message that the password has been changed but the acknowledgement never reaches the client which keeps it's old password. Similar issue with 2K3 file servers and Windows 7 clients with realy slow access and the green bar constantly moving.

                          http://windowsitpro.com/windows/q-ca...t-s-password-e

                          If this was the way AD behaved by design, then nobody in the NT days could have logged on after a 2 week holiday, and if that was the case Microsoft would have been slaughtered for it.
                          BSc, MCSA: Server 2008, MCSE, MCSA: Messaging, MCTS
                          sigpic
                          Cruachan's Blog

                          Comment


                          • #14
                            Re: Managing off-site machines with only a corporate DC

                            You're quite right in that problems with broken trust relationships between PCs and Domain Controllers were basically unheard of in the NT/2000/2003 era, even though, as you say, the password interval was much shorter back then.

                            I think it's fair to conclude that:
                            1. the password change interval is not directly related to the issue, otherwise any computer left without network connectivity for n days, where n is the interval, would immediately experience a broken trust relationship (and as you say, the interval used to be 7 days)
                            2. the password update mechanism is somehow related to the broken trust relationship, as the problem doesn't occur on systems that regularly contact a DC to change the computer account password

                            "Trust relationships" must be related to encryption/signing keys, and as with all keys in Kerberos-based systems, they expire after a time and must be rotated. My guess is that a password update forces rotation of these keys or perhaps re-signing of <something>, just as it does with EFS keys tied to user accounts.

                            Speculation: Perhaps the broken trust is the result of a failed password update on a computer account where the flag "password must be changed at next logon" is set. After all, when that happens to a user account, encryption keys are lost.

                            Like you, I can't remember ever having this problem on Windows NT or Windows 2000 systems. First time I ever saw it was on a Windows XP system in a Windows 2003 domain, but it's only in Windows Server 2008 R2-based domains with Windows 7 clients it's been a frequent problem.

                            This sums up my experience with broken trust relationships:
                            • Pre-Windows 2003 domains with pre-Windows XP clients: The problem was unheard of.
                            • Windows 2003 domains with XP or Vista clients: I've seen it only a handful of times, and in those very few cases it could very well have been caused by some random/unrelated client issue.
                            • Windows 2003 domains with Windows 7 clients: I only have 5 clients still running a setup like this (2003 SBS, mostly), and there are no more than 20 PCs in each network. But for what it's worth, none of them have ever had this problem, even though their laptops are frequently disconnected from the domain for days and weeks at a time.
                            • Windows 2008-based domains with XP/Vista/7 clients: I don't have enough data to draw any conclusions. Most clients with 2003 DCs dragged their heels to the extent that by the time plans for migration were approved, 2008 R2 was available and they just skipped 2008 altogether (on the DC side). I've had few clients that were using 2008 SBS and a mix of XP, Vista and 7 clients, and while I'm not exactly fond of 2008 SBS for a variety of reasons, broken workstation trusts isn't one of them.
                            • Windows 2008 R2-based domains with XP or Vista clients: Hardly ever saw the problem.
                            • Windows 2008 R2-based domains with 7 clients: Trust relationships are lost frequently enough for it to be a real nuisance.

                            You could very well be right about the problem first appearing in Vista, but going unnoticed until 7 became prevalent. I've actually sold and installed a significant number of PCs with Vista Business, but the vast majority of them were desktop systems. For performance reasons, laptop users wanted to stick with XP, which means the Vista systems were mostly using a permanent, wired network connection.

                            Comment


                            • #15
                              Re: Managing off-site machines with only a corporate DC

                              Originally posted by Ser Olmy View Post
                              The feature you're looking for, is called 'conditional forwarding'. Most DNS servers are capable of this, including the caching DNS servers found in many routers. The question is whether or not your router has a proxy DNS feature, and if so, if the manufacturer has included settings related to conditional forwarding in the management GUI.
                              Unfortunately, meraki doesn't support this. And since setting a secondary public DNS is not recommended, I don't know how else we can keep the relationship with the domain and get gpupdates and password updates etc. (see my next comment)

                              Comment

                              Working...
                              X