Setting up a DC for dev/test?

  • 64 Views
  • Last Post 27 July 2015
dsolodow posted this 20 July 2015

We have an account automation tool that does a lot of work with AD users/groups/etc, and after a recent hiccup there is strong interest in having a dev/test instance of the tool.

The problem with that, is that it would need a non-live DC to talk to. J   So the question is, how do I safely have a non-production DC that can be easily (relatively) updated with data from our actual domain?   Unfortunately since the automation support and contractor are remote, I don’t see a way to airgap the test DC.   One possibility I considered was to have a DC that lives in its own site, that doesn’t perform outbound replication. But that has the issue of changes made to the local copy not necessarily being overwritten by inbound replication which would cause sync issues.   Part of me thinks the right answer is a local VM that’s isolated from the network, but then I’d have to have the contractor either run it locally (which would create issues around sending AD updates) or allow them console access to the VM from vCenter.   Anyone have a good solution for this type of scenario?     DAMIEN SOLODOW Senior Systems Engineer 317.447.6033 (office) 317.447.6014 (fax) HARRISON COLLEGE 500 North Meridian St Suite 500 Indianapolis, IN 46204-1213 www.harrison.edu  

Order By: Standard | Newest | Votes
Mahdi posted this 20 July 2015

I am not sure if I am on the right trail or not but what is the expected behaviour of this tool with RODC?










Sent from my BlackBerry 10 smartphone.















show

















We have an account automation tool that does a lot of work with AD users/groups/etc, and after a recent hiccup there is strong interest in having a dev/test instance of the tool.



The problem with that, is that it would need a non-live DC to talk to.

J

 

So the question is, how do I safely have a non-production DC that can be easily (relatively) updated with data from our actual domain?

 

Unfortunately since the automation support and contractor are remote, I don’t see a way to airgap the test DC.

 

One possibility I considered was to have a DC that lives in its own site, that doesn’t perform outbound replication. But that has the issue of changes made to the local copy not necessarily being overwritten by inbound replication which

would cause sync issues.

 

Part of me thinks the right answer is a local VM that’s isolated from the network, but then I’d have to have the contractor either run it locally (which would create issues around sending AD updates) or allow them console access to the

VM from vCenter.

 

Anyone have a good solution for this type of scenario?

 

 

DAMIEN SOLODOW

Senior Systems Engineer

317.447.6033 (office)

317.447.6014 (fax)

HARRISON COLLEGE

500 North Meridian St

Suite 500

Indianapolis, IN 46204-1213

www.harrison.edu

 

g4ugm posted this 20 July 2015

When I worked we have a separate VMWare environment. We had a VStore provided by a SAN  that was shared between live and production, so you could clone a live VM to this VStore and then import it into the test VMWare. It was expensive as it needed two Venter licences but perhaps you can get away with the VCenter appliance these days. I also seem to remember that I had to do some tweaking to get multiple DC’s to replicate when cloned in this way… Dave 

show

KenHooveroxfordcomputergroupcom posted this 20 July 2015

Having a non-production “functional replica” of your AD is a huge advantage when deploying any AD-integrated tools and I strongly recommend it.

 

You could perhaps use your identity automation tool to “seed” the new AD with accounts, groups, etc from production.

 

I’ve also seen non-prod AD’s created by cloning production DC’s but that tends to cause confusion down the road because of the duplication of domain

names, SIDs, etc.



 

Ken Hoover

 

--

Ken Hoover | Senior Consultant | Oxford Computer Group NA



 

show

dsolodow posted this 20 July 2015

Since the tool in question makes changes to AD, and RODC wouldn’t work.

 



DAMIEN SOLODOW

Senior Systems Engineer

317.447.6033 (office)

317.447.6014 (fax)

HARRISON COLLEGE



 

show

dloder posted this 20 July 2015

+1
a real test environment is much more useful than trying to clone/isolate prod.
-- http://dloder.blogspot.com --
 




show

kevinrjames posted this 20 July 2015

Important considerations for selecting a method include; A replica copy with the same SIDs and GUIDs, snapshots of user passwords, etc. Must consider the entire Production forest for any replicas. Some child domains may not be needed but the root will be needed. A representative copy where SIDs, GUIDs, Schema, and Passwords do not need to be the same as in prod. A fully isolated environment for the first case must be maintained along with refreshes as required. Plus the entire forest considerations. Representative AD forests can co-exist as a dev/test and adapted as needed.  Really all depends upon what you’re trying to accomplish. /kj 

show

dsolodow posted this 20 July 2015

That’s what I thought. The question then is how do you keep the test environment reasonably synced up with prod? It is just a matter of a batch of ldif export/imports?

 



DAMIEN SOLODOW

Senior Systems Engineer

317.447.6033 (office)

317.447.6014 (fax)

HARRISON COLLEGE



 

show

dsolodow posted this 20 July 2015

It’s a single domain forest, so that simplifies things a bit.

J

For dev, doesn’t need the same sid, guid, passwords. The important parts will be:

OU structure

Same Groups and members

Same users and most attributes (samaccountname, upn, mail, company)

 

Basically the goal is to be able to make changes to our account automation scripts and do a trial run on a recent copy of prod data.



 



DAMIEN SOLODOW

Senior Systems Engineer

317.447.6033 (office)

317.447.6014 (fax)

HARRISON COLLEGE



 

show

g4ugm posted this 20 July 2015

I think another important point is that if you create a simple and successful test environment you may suffer scope creep , in that when folks see it works they will want to use of for more things than you planned for and may have capacity issues. Another consideration is are you going to use the same IP address range, or will the network team make you have a different rang.  After many years I have come to the opinion that whilst testing is valuable the scope of what you can duplicate and test is usually limited, so you still need to plan to put mediation in place to cope with unforeseen issues. Dave 

show

MikeLeone posted this 20 July 2015

On Mon, Jul 20, 2015 at 11:57 AM, Damien Solodow

show

dloder posted this 20 July 2015

You can use home-grown scripts, or something like FIM.  I believe that the FIM license just changed and the Sync engine is now included with all Windows Server licenses.
-- http://dloder.blogspot.com --
 




show

KenHooveroxfordcomputergroupcom posted this 20 July 2015

IMO the nonprod environment needs to be a good “representation” of production but not necessarily identical in every way.

 

For example, it should have all of the major AD-related components that you use – Exchange, Sharepoint, your user provisioning tool, etc.  However,

it doesn’t need to have 100% of your user community in it. 

 

Having this parallel-world AD allows you to do things like test upgrading DC’s or Exchange in a reduced-risk environment before applying the changes

to production.

 



Ken Hoover

 

--



Ken Hoover | Senior Consultant | Oxford Computer Group NA



 

show

barkills posted this 20 July 2015

We chose the representative copy route.



 

Our various provisioning solutions that integrate our AD with our much bigger identity and access management ecosystem are self-aware of what domain they are

running in, and have slightly different behavior based on that. So for example, we don’t provision actual passwords to our dev AD, instead provisioning a long random password and disabling the user unless the account is in a group of “enabled users”. These

minor differences are acceptable and easily maintained, and allow us to test all the other changes we make to these integration components as well as test changes to significant applications like Exchange which may have some issue with our AD configuration.



 

One downside of this route is that there is a bit of extra work to maintain the dev AD, e.g. we have to manually enable user accounts in it, but with this approach

the attack surface and risk is greatly reduced.

 

show

eccoleman posted this 21 July 2015













We do exactly as Ken describes, but use FIM to synchronize people/account objects representing staff & students from production to the dev/test. We do not synchronize passwords, but have a separate tool (not the FIM portal) to reset passwords. We also

do not synchronize groups or OUs, but FIM certainly has that capability.










--

Erik Coleman <ecc@xxxxxxxxxxxxxxxx>

Senior Manager, Enterprise Systems

Technology Services at Illinois

University of Illinois at Urbana-Champaign





















show

gkirkpatrick posted this 22 July 2015

I wrote some PowerShell scripts that take LDIF dumps (config and domain) from a live forest and provision new DC(s) in a Hyper-V environment and promotes and loads them appropriately.

It even creates all the sites and stuff (but no subnets)… it’s up to you to fiddle with the networking and put the DCs in the proper sites. If you’re interested I’ll dig them up.

 

-g

 

show

SmitaCarneiro posted this 22 July 2015

Gil,

 

I’d be interested in these scripts too.

 

Thanks,

 

Smita

 

show

Patrick posted this 22 July 2015

Gil post the script - I am very interested since I have finally committed to learning Powershell.


show

webster posted this 22 July 2015

Please post the scripts. You are welcome to write an article and post the article and scripts on my site.

 



Thanks

 

 

Webster



 

show

dmourya posted this 22 July 2015

Hi Gil,

 

I am interested to have this script and test in my environment, as I have to build a test environment of my existing environment.

 

Thanks & Regards

Dinesh Mourya

 

show

gkirkpatrick posted this 23 July 2015

Is everyone happy if I put them on a source code repo like GitHub? Or NuGet?

 

-g

 

show

Show More Posts
Close