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

dsolodow posted this 23 July 2015







Seems more like a GitHub thing than a NuGet. :)









DAMIEN SOLODOW



Senior Systems Engineer



317.447.6033 (office)



317.447.6014 (fax)



HARRISON COLLEGE












show

gkirkpatrick posted this 23 July 2015

I agree. But VS supports PowerShell projects, so…  who knows?

 

-g

 

show

tim.medina posted this 23 July 2015

What about posting it at poshcode.org?




show

dje31 posted this 23 July 2015

Hello Gil,
I'd be interested too.
Thanks,Jérémy.


show

dsolodow posted this 23 July 2015

Supports GitHub too. ;)

 



DAMIEN SOLODOW

Senior Systems Engineer

317.447.6033 (office)

317.447.6014 (fax)

HARRISON COLLEGE



 

show

gkirkpatrick posted this 26 July 2015

It’s nice to see so much interest.

 

I’m going to clean them up and put them on GitHub. As I’ve only used them in my own environment with one customer’s data (and my own

contrived test data), I’d like to get one or two people to test them out before I unleash them on the world. Does anyone have some spare cycles over the next week or so to work with me testing them?

 

You’ll need a Hyper-V environment capable of supporting 3 concurrent VMs, a copy of the WS2012R2 ISO and some LDIFs from a the config,

schema, and domain NCs of an interesting AD environment. I’d like to test out both single and multi-domain forests with more than one site if possible.

 

First two respondents…

 

-g

 

show

kevinrjames posted this 26 July 2015

Count me in .. if soon enough.   /kj 

show

EnterpriseAdmins posted this 26 July 2015

I'm actually struggling to find a way to stand up a test environment of some domains I have access to but not at the DC level, this would be awesome!
Sent from my iPhone

show

robertsingers posted this 26 July 2015

Gil have you considered doing the same thing from on premise to Azure?  If you're not managing your own tin cloud IaaS can be the preferred option for non-prod environments.
Sent from my iPhone


show

deji posted this 26 July 2015

Gil,



Is Hyper-V required simply for Powershell/scripting reasons or are there some special dependencies between your tool and the platform? I am interested and would like to be included, but I'll be looking to kick it around on a different hypervisor if you won't mind.

show

gkirkpatrick posted this 27 July 2015

Hi Deji,

That would be cool. There's nothing inherently tied to Hyper-V; so long as you have adequate PoSh support, you should be good. Basically you need to be able to (via PowerShell) clone a VM from a saved sysprepped disk image, and configure networking to support communications between several VMs and the host. I think that's about it for hypervisor dependencies.

There are really three aspects to this project: 1) parsing the LDIF files, 2) creating VMs based on that information, and then 3) configuring the DCs and populating the AD data. You could certainly replace the cmdlets from 2) with whatever you need for VMWare (or whatever hypervisor you're using).

-g

show

gkirkpatrick posted this 27 July 2015

Looks like Michael and Jonathan Hassel win the prize! It should only take a week to get them ready for everyone else, so be patient.

 

Michael and Jonathan, can you send me LDIFs of your environments (assuming they don’t have any sensitive information)? Basically I

need 3 LDIFS from each, ala:

 

C:> LDIFDE -d CN=Configuration,DC=foo,DC=local -p SubTree

C:> LDIFDE –d CN=Schema, CN=Configuration, DC=foo,DC=local –p SubTree

C:> LDIFDE –d DC=foo,DC=local –p SubTree

 

I just want to test them here to make sure everything is copacetic, then I’ll send them to you to play with.

 

-g

 

show

dje31 posted this 27 July 2015

Hi,
I can test it, if you want, i got a vmware test lab, so i can manage to make it work on it.
ThanksJérémy.


show

Close