I'm looking for some advice and answers on a design we're hoping to implement at work.

Basically, we want to create a separate sub/child domain for our lab servers and equipment to be a part of. The hope is that this domain can be below our corporate domain, allowing us to manage our own equipment, devices, and usergroups. The only thing that we really need is to extend corporate usernames and logins to our lab domain.

For instance, we have an application server that will be joined to our lab domain controller. Logins to this server should be passed up to the corporate domain, but access privileges (groups) will be managed on our lab DC by us, not IT. Our thoughts were that we could do this with a 1-way trust. IT is telling us that it doesn't work this way, and that we will have to use LDAP from our domain controller. That makes things more difficult because of the requirement for different access groups.

First, is IT correct? Second, is there a better way to do this?

10/18/2011 3:48:05 PM

Nobody?

10/18/2011 11:56:46 PM

lets say the root domain is corp.local and your new lab domain is lab.corp.local

there are two ways to do it.

one is to create a totally separate forest and setup a trust between domains. So you'd install the new DC as if the other domain doesnt exist at all. Setup your own dns for lab.corp.local and everything as if theres nothing on corp.local. Then once everything is good you would configure a trust between lab.corp.local and corp.local. you'd also want to setup dns forwarding so lab.corp.local sends everything corp.local to the corp.local dns servers.

This method is nice because you can always delete the trust from corp.local and everything is back to normal. The downside is it may be a little harder to build out the permissions.

the second one is to add lab.corp.local as a child domain to corp.local. This can be done through the AD creation tool iirc. You just specify that you want to create a new child domain under an existing one. When child domains are created the trust is automatically configured. any users created under lab.corp.local only have whatever default privledges in lab.corp.local. they wont be able to do anything in corp.local unless someone in corp.local gives them access. Once setup, you would then deligate control over lab.corp.local to whatever lab group in corp.local. This would give your lab groups control over the lab domain (using corp.local logins) without giving you any additional access to corp.local.

The upside is that the trust, dns, and permissions config become very easy. The downside is that this domain is more tied into corp.local because its now in the same forest. If you ever want to delete it you would probably have some extra steps beyond deleting the trust. I'm not actually sure what might be a problem, but anything that is shared (ex: DNS) would need to be looked at. On the other hand it may clean it all up for you since it knows everything about the child domain.

10/19/2011 1:08:00 AM

Thanks! That's what we kind of had in mind, but IT is very hesitant to let us join a new DC to the corp domain - particularly because it's "lab" equipment. It's a matter of proving minimal risk to the corporate network/domain, and showing that what we want to do is possible.

10/19/2011 5:01:03 PM

A subdomain really isn't justified in this scenario. Subdomains are generally created based on geographical divisions to accomodate slow network connectivity and diverse regulatory environments.

It sounds like you simply need delegation, which is best accomplished with an OU. If you scale out your architecture to a large company with lots of labs and departments, you create a royal clusterfuck and you gain nothing.

Here is a good article that discusses a number of misconceptions about multi-domain forests.

http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/68/Default.aspx

[Edited on October 19, 2011 at 11:05 PM. Reason : ?]

10/19/2011 10:55:48 PM