Active Directory question
-
I'm looking at creating a new AD config from scratch to replace one that was created long before me with Server 2003. I've done a lot of reading over the years and I'm still unclear on some things. Maybe someone here has some insight.
Assuming our base domain is company.com, you are advised to create a forest with your base domain and then create child domains for your actual AD users, so company.com would be the forest, and ad.company.com or lan.company.com or internal.company.com would be the child domain that the users and computers would be members of.
But I've also read about single forest-single domain installs, where the forest is also the domain. In this case, you would create the forest company.com and then your users would log into company.com. The only downside I could find was split DNS issues, which is nothing if you only have a few internal NAT hosts to manage.
The only reason I can see for having a child domain from the forest is for test/dev purposes. For example, I need some software developers to be domain admins when testing software in a real environment, but I don't want them to be actual domain admins on our corporate domain. In this case, I would have company.com as the forest/domain, and then dev.company.com or test.company.com as a child domain.
Is anyone else aware of any downsides to using a single forest-single domain model? Am I missing something obvious?
-
For smaller companies, I see little advantage in not using a single domain model. In my experience, using your Internet facing domain (company.com) causes more trouble than it's worth and you are better off using something like company.local instead.
-
But why? What 'trouble' should I be concerned with? I guess that's my root question here.
-
As long as you us subdomains from your public you would be fine.. ad.domain.com for example.. But I too wold stay away from public same as your private.. If you own domain.com and domain.net you could use your .net as your local domain and nothing public on it.. And use domain.com as public facing..
You can run into bad stuff that can be a pain with split dns even.. Its just better to keep your domains different than public facing.. And not sure how dev testing software in real would require domain admin.. If your software requires domain admin to work - its WRONG!!!
But isolation of other domains is yes the biggest reason you would stay away from single domain same as forest..
-
@kom Mainly the split-DNS issue. You've got two places to update DNS records now. The AD servers will also spam the authoritative DNS servers, which is annoying if you are managing them.
-
And not sure how dev testing software in real would require domain admin
Our software is used exclusively in AD networks, so testing involves having servers that are part of the domain. When you're testing with virtual machines that are part of a domain and you roll back to a previous snapshot, the domain trust is broken and you have to remove and then re-add the server to the domain. Plus, our solution relies on Microsoft DFS Namespace support, and I don't want them playing around with that on our real domain. That's why they need domain admin for some things. I know that I could probably design something else but this is the way it's always been done since before my time, and I'm planning on redoing EVERYTHING this Fall when Server 2019 comes out, so I'd rather not make any changes to what we have that works now.
Mainly the split-DNS issue.
OK then, I'm not concerned. I literally have two NATs to worry about, so split DNS for those will take 2 seconds to create and will likely never update.
I think I will stick with the single forest-single domain model. Thanks again, guys.