1

My company sells software solutions to customers and as part of the delivery we also provide the hardware and configuration.

Despite on paper all the hardware and operating systems belonging to the customer, we perform all of the administration (customers are only given access to the servers if they request it - which we can't really deny since they own it -, but this is quite rare). This is done through a normal VPN connection to the customer.

Up until now, we've left everything in a workgroup, but as the company grows, it's starting to difficult to manage things this way.

Internally, we already use Active Directory (let's call this forest internal.local. The current plan is to create a separate forest that would also live in house (let's call it customers.local) and to then create a subdomain for each of our customers, i.e., customerA.customers.local, customerB.customers.local, etc. Each subdomain would have a single DC directly on the customer's site.

The idea is then to have a one way external trust between internal.local and customers.local, so that the helpdesk can use their accounts from internal.local to connect to all of the customer's devices.

Where I can see a potential problem is the fact that often customers switch off some servers for no reason whatsoever and because they belong to the customer we can't choose to switch them back on ourselves. This means it's not uncommon to be in a situation where a customer had a server powered off for 6 months or longer.

I know that credentials are cached for a period of time (configurable) when authenticating against the domain a computer is in, but my understanding is that when authenticating over a trust (or even from child to parent domain?) that no credentials are cached. Is this correct?

If that's the case, then the second a customer's sole DC is down the helpdesk would not be able to authenticate using their users from internal.local, even if they had just connected 5 minutes before.

Can someone clarify whether this is the case?

Also, if indeed a DC happens to be down for a long period of time, what will the consequences of then bringing it back online afterwards be and what configuration needs to be rectified?

JP Trust
  • 11
  • 1
  • This is not a good solution and my initial opinion is that you'll find very few customers willing to go this route, unless they're completely clueless. I don't understand how or why the current solution becomes more difficult as you scale up. Maybe you can detail some of the difficulties in your question so we can better understand your situation. – joeqwerty Apr 03 '17 at 13:47
  • 2
    `.local` domains make baby Jesus cry. So do child domains, now that I think of it. And don't take this as an endorsement of your architecture, but if you go down this "one domain per customer", then it needs to be a separate forest per customer, as forests are the security boundary, not domains. – HopelessN00b Apr 03 '17 at 13:52
  • What's so wrong with `.local` domains **when** A) Company doesn't want/cannot buy a domain name and B) nothing that's on that domain has internet access (not even for DNS)? Granted there are a few better non-TLD names that can be picked, but for most people in these situations `.local` does the job just right (and yes, I know about the potential problems with `mDNS`) – cogumel0 Apr 03 '17 at 19:49

0 Answers0