Domain Design Guidance

  • 255 Views
  • Last Post 16 August 2018
kcnymailer posted this 16 August 2018

Hello Community,

My organization currently has several independent forrests, with a single domain per forrest, and no trusts in between.  We struggle with environmental fidelity because the environments (e.g. test, integration, production), are not used in the desired fashion.  Most units have their test/int systems bound to and authenticating against, production AD.

I find myself at a crossroads in order to better prepare our AD environment for regression testing against major changes, such as upgrades that would impact domain/forrest functional levels.

From my perspective, we have two, SUPER high level options:

-Take systems that are bound to production, which should be bound to test or integration, and bind them to the respective AD environments.  The biggest downsides I have observed so far are impact to applications, and user experience since most of our apps utilize Kerberos authentication.  We've considered provisioning terminal servers in these domains for application testing and interaction, but that's not popular from an end user standpoint.  While this is the path of least technical implementation, it probably wouldn't be worth the effort, necessarily.

-Build out an entirely new domain infrastructure, where we build a new parent domain, and move towards sub domains.  This is the heaviest technical lift comparing between the two options, but IMO, the best long term technical approach. 

Curious if others can point me to information or provide some guidance on how best we could achieve our goal, with the setup we have.  Also, do we have the ability to effectively test our changes (e.g. upgrade Domain Controllers from 2012R2 - 2016/2019, raise relevant functional levels) incrementally, if we go the subdomain aspect?

Appreciate any assistance you can all provide - thanks.

Order By: Standard | Newest | Votes
bdesmond posted this 16 August 2018

It sounds like you have about what most people have. I haven’t seen many organizations be very successful forcing every app into a pre-prod AD environment. I also haven’t seen many organizations be successful forcing every app owner to

do regression testing against an AD upgrade.



> Build out an entirely new domain infrastructure, where we build a new parent domain, and move towards sub domains.  This is the heaviest technical lift comparing between the two options, but IMO, the best long

term technical approach. 

I don’t think this is necessarily your best approach. Building a new single-domain forest that you collapse your independent forests in to might be a good plan, but, adding child domains is unlikely to buy you anything other than unnecessary

complexity. I’d weigh building a new forest against collapsing into the largest/most complex existing forest to make the project go faster/cost less. These aren’t the sort of projects that tend to have much in the way of measurable ROI but they generally come

with a pretty high price tag.

 

Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132.

 

show

barkills posted this 16 August 2018

It sounds like you have about what most people have. I haven’t seen many organizations be very successful forcing every app into a pre-prod AD environment. I also haven’t seen many organizations be successful forcing every app owner to

do regression testing against an AD upgrade.

[BA] Totally agree. We’ve only ever gotten an application to use our test forest after a change in production broke them, e.g. we upgraded our DCs, the encryption algorithm order changed, and we needed them to verify that our proposed

change would fix their production application.


> Build out an entirely new domain infrastructure, where we build a new parent domain, and move towards sub domains.  This is the heaviest technical lift comparing between the two options, but IMO, the best long

term technical approach. 

I don’t think this is necessarily your best approach. Building a new single-domain forest that you collapse your independent forests in to might be a good plan, but, adding child domains is unlikely to buy you anything other than unnecessary

complexity. I’d weigh building a new forest against collapsing into the largest/most complex existing forest to make the project go faster/cost less. These aren’t the sort of projects that tend to have much in the way of measurable ROI but they generally come

with a pretty high price tag.

[BA] Totally agree. If this was my problem, I’d set an end date on the test & integration forests ~2 years out and inform customers that they need to shift their practices to the production forest (or your AAD-DS). Note: I have no

plans to get rid of our test forest because we have custom code that is core to how we run our AD which we need to test somewhere before we release it. The other thing I’d add is that given modern application deployment practices and the shifting direction

of Microsoft applications (and specifically a shift in their need to be domain joined), I have serious doubts about how many apps will really need AD in the future (and I’m talking 5-7 years from now). As an example, if you are using containers, you can’t

build an app in a container that has a domain join dependency. From a forward-looking perspective, I don’t think AD will continue to be an app integration focus, and I would certainly counsel my organization against spending much on making changes to AD to

support applications and instead put that investment in Azure AD and other more forward-looking application integration approaches.


 

Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132.

 

show

robertsingers posted this 16 August 2018











You actually need to solve the real problem before you do any design work.  Your organization sounds like one that hasn't grasped that managing its software lifecycle is a production activity.  Work out why you're creating security boundaries and what you're

protecting against and the best approach will become self evident.









--rsingers







show

Close