Remote Site / Domain Controller question
We have a remote office that we're setting up equipment for next week. I have a server that will be going down to provide local services such as DNS, DHCP, logins, file storage, etc.
I've ran into a problem that I'm a bit unsure about, so I thought maybe I would get some input.
I want to centralize administration as much as possible without forcing the other site to rely on the site to site VPN connection, meaning I do not want them to have to login to our domain controller here at the main office, don't want them to rely on our server for DNS, DHCP, etc. I want them to exist as a self sufficient office, but I would like to be able to handle user accounts and so on, from our main office.
From what I have seen, the easiest way to accomplish this is by making them a secondary domain controller. I have also considered, or researched, trust relationships and child domains, neither of which seemed to be ideal for this situation.
Could someone with more AD experience than myself comment on this? What are your thoughts?
Also, this will not be the only remote site. In the future, there will potentially be more, so I am wanting to setup a configuration that can be duplicated with each site we deploy.
Feel free to toss around ideas as to the best way to do this, as I am completely open for discussion!
I've ran into a problem that I'm a bit unsure about, so I thought maybe I would get some input.
I want to centralize administration as much as possible without forcing the other site to rely on the site to site VPN connection, meaning I do not want them to have to login to our domain controller here at the main office, don't want them to rely on our server for DNS, DHCP, etc. I want them to exist as a self sufficient office, but I would like to be able to handle user accounts and so on, from our main office.
From what I have seen, the easiest way to accomplish this is by making them a secondary domain controller. I have also considered, or researched, trust relationships and child domains, neither of which seemed to be ideal for this situation.
Could someone with more AD experience than myself comment on this? What are your thoughts?
Also, this will not be the only remote site. In the future, there will potentially be more, so I am wanting to setup a configuration that can be duplicated with each site we deploy.
Feel free to toss around ideas as to the best way to do this, as I am completely open for discussion!
Comments
-
cnfuzzd Member Posts: 208A second AD site is what you are looking for. You can either enable universal group membership caching, or make it a global catalog server, depending on the bandwidth (lots bandwidth = gcs).
Really, its not that complicated of a setup. There are tons of articles around on this.
John__________________________________________
Work In Progress: BSCI, Sharepoint -
Jordus Banned Posts: 336cnfuzzd is correct.
By giving the remote site its own DC and creating a site for it, you can manage traffic routes and also reduce a lot of traffic that goes to the main office. It will also allow logons if the WAN link goes down as well. -
HeroPsycho Inactive Imported Users Posts: 1,940If the WAN link is problematic, consider two domain controllers per site as well.Good luck to all!
-
blargoe Member Posts: 4,174 ■■■■■■■■■□These other folks are correct from what I can surmise from your post. Unless you have a need for a separate administrative boundary, you should just use a site. In fact any remote office should always be its own site regardless of whether you decide it needs a new domain or not.
Just make sure you define EVERY subnet that will be associated with that new office in Active Directory... or you could have computers making a guess as to where they should be authenticating, and those guesses aren't always the most intelligent. For that matter, make sure you go back and check that all the subnets for your main office are put in.
Make it a global catalog unless it's a busy or slow link. Two DC's if you can afford it. Should be OK to also host DHCP and DNS on the DC.
If you're going to have other IT people in that office helping you out, put their computers and user accounts in a separate OU and do delegation of authority to give the rights they need.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...