AD 2012 multi-tenant best practices

  • Last Post 21 September 2016
CKaiser posted this 20 September 2016

Hi folks. I've been quiet for a loooong time but still here... Need some

Been a while since I have had to architect this type of scenario so I'm
looking for some more recent guidance...

Hosted datacenter environment with many (>100) clients. We host client
environments and serve their apps to the client workstations via Citrix.
Management wants a complete redesign of the domain/forest structure to take
care of the last 5 years of mergers and acquisitions, and the customer
domains should be included. Regulated industry so isolation of data is
critical. For years the mantra was "the domain is the security boundary", so
it has been one domain per client (and that is still my current thinking).
But we (architecture team) are being told "make it one large customer domain
that is part of our corp forest" but client workstations will be in another
untrusted domain using Quest (or similar tool) to provide sync services.

Exchange will be hosted by Office365 so an Exchange farm is not an issue.
Servers such as file/DB/App will be client-specific, not shared. So why
would we want to create a single domain housing all of those servers? I
don't see this as a good idea but I am remaining open-minded.

I am looking for some documentation that discusses this. I've read several
articles that discuss DC placement (mostly irrelevant for us) and security
permission lockdowns to isolate clients per OU. Frankly, the latter seems a
recipe for disaster. One missed ACL and you're hosed...

I welcome all discussion and ideas. Thanks!


Charlie Kaiser
Kingman, AZ

Forum info:
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
barkills posted this 20 September 2016

I don't quite understand the advice you are being given--maybe the suggestion you are hearing (from management?) is an account forest/resource forest model (with single domain per forest), with the client computers in the resource forest that trusts your account forest. There are then two problems to solve--isolation of user (and group) data & isolation of admin privileges on computers.

The first is doable, but with a set of consequences that may be unexpected or outside your experience. I talk about these kind of issues here: The second is also doable with a delegated OU approach, but you'd have to weigh the risks, and work out the sticky bits in any delegated OU scenario--things like how to deal with namespace issues (computer names, GPO names, etc.)

I don't think most organizations feel comfortable accepting those risks, and instead would separate each customer into their own single domain forest that trusts the account forest.

We run with both of these models--mostly because we don't have a single IT authority that speaks for everyone, but also because we don't have the luxury of being able to redesign all at once. Some of our departments have their own forests and they trust our central forest as an account (and group) forest--and initially no one trusted the delegated OU model enough so they were all separate. But these days an overwhelming majority of departments have a delegated OU in the central forest. And I'd guess about half of those with a delegated OU also have a separate single domain forest which they are either using to host servers or are slowly migrating into their delegated OU.



ken posted this 21 September 2016

If you are in a regulated industry, then:
a) what are the requirements/standards you need to adhere to?
b) are you going to be audited? And if so, what controls (whether that be technical, process, whatever) do you need to show are working?

That should be your starting point IMHO - because they form the basis of your requirements. You can work out the right mix of technology components, operations processes etc. later.


kurtbuff posted this 21 September 2016

From my understanding - the domain is not the security boundary -
the forest is the security boundary.