Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 480
  • Last Modified:

Active Directory over VPN

Hey guys

I am about to setup a few servers in remote locations.  They will all be connected via VPN to the main office and all on Active Directory.  I want to just have the main Active Directory server in the main office and the remote locations authenticating via the VPN to the main office's DC.  
The VPN's are all hardware VPN (the Routers in each location will be handling Gateway to Gateway VPN's)
Each location of course will have its own IP subnet... i.e. main office is 192.168.200.xx and the remote locations will be 192.168.201.xxx and so on up to 192.168.220.xxx.

Now, here is the question I have.  What do I need to do to the DNS Settings on the Active Directory DC to make all sites work properly?  I have done this in the past and didn't do anything and it just had a lot of problems, so I am suspecting that I should have done something to the DNS Settings (i.e. add a reverse lookup zone for each area).

Looking forward to the Experts help!!

Thanks!!
0
jonmenefee
Asked:
jonmenefee
  • 8
  • 5
1 Solution
 
Chris MillardCommented:
Well, I guess the first question I would ask is WHY do you want all of the authentication to be done at the main office? What if a VPN tunnel goes down - what do the staff at the office do then?

The better solution may be to have RODCs (Read Only Domain Controllers) at each remote location.

Anyway, specifically to your question, assuming all machines are on the same domain, then you should have a forward lookup zone for that domain, and you should then have reverse lookup zones for each IP range.

However, your question doesn't really mention what problems you've had in the past that you are trying to overcome this time.
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
Based on your needs you can have all of the sites authenticate to the main office. How many people on average would be at a single site? Also what is the bandwidth for each site? Are you running apps out of the remote sites?

As state you could use RODC's but then you have a lot more management in regards to servers etc.

If you are authenticating to the main site your remote sites will need to have DHCP setup with DNS point to your DNS servers in your main site.

That being said if you are using DNS in the main office it will also use the forwarders on your DNS server for Internet questies as well. This is not good because all internal and external traffic will be going out of your main site which will slow users internet traffic while they are in the main office.

What you should do in your main office is on your router setup rules so that if it is an internal DNS traffic (192.168.200.x) then use Ethernet1 if it is anything else (internet) then use Ethernet2.


Will.
0
 
jonmenefeeAuthor Commented:
I am actually thinking that putting a RODC might be the best option. Is there anything I would need to setup on the main DC's DNS if I setup an RODC at each individual site?
0
Lessons on Wi-Fi & Recommendations on KRACK

Simplicity and security can be a difficult  balance for any business to tackle. Join us on December 6th for a look at your company's biggest security gap. We will also address the most recent attack, "KRACK" and provide recommendations on how to secure your Wi-Fi network today!

 
Will SzymkowskiSenior Solution ArchitectCommented:
There is nothing that need to be at the main office DC. You do however need to make sure that the Subnets for each of the sites are listed in AD Sites and Services.

When you install an RODC in the remote locaitons you will be able to open ADDS and DNS manager but you will not be able to modify anything on this server hence Read Only.

I would test this at a single site First and then proceed. If you have a remote site with less then 20 users I would not both putting an RODC in this site, as it just generates overhead and administrative work. I would only put RODC where needed and not just because it is a remote site.

Will.
0
 
jonmenefeeAuthor Commented:
Ok. Let me make sure I have this right. If I do or don't put an RODC at a site do I still go in and make sure that the remote site is in the AD Sites and Services?  
Here is what is happening at these sites. Each site will be a SQL Server that the people in that country will be using. The servers will be the only machines at each of the sites and all of the servers will be Publications and Subscribers. (Peer to Peer)  right now the only SQL server that is working properly is the one at the main office with the DC next to it. A pilot site has lots of issues and they all seem to be AD related so that is why I am thinking about the RODC at each location
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
When you have an RODC in your environment changes still need to be replicated to these DC's to update there information. RODC do not cache passwords and cannot have data written to the NTDS.dit database. If your application "requires" you to have a writable DC in your site then an RODC will not work.

The other thought was there might be latency issues from your remote site and the applicaiton you are using. If you have a decent connection 10mbps that should be more than enough to service a small remote office.

If all of your DNS settings are correct and they are point to the main office DC/DNS servers you should have no issues remotely.

What are the issues they are facing. If you provide some of the details we can help make a more ideal solution.

Will.
0
 
jonmenefeeAuthor Commented:
Some of the errors in the pilot site are that it is not getting the group policy and that it cannot find the DC. I can use NSLOOKUP though at the remote site and it sees it. I can ping and tracert using name and IP address. The only DNS in the connection configuration is the main DC and I was able to join the domain. The connection is 10mbs so it's fast enough. The main site is getting group policy because it requires ctrl-alt-del to login when absent for a period of time. The remote site doesn't seem to get the policy because it never requires login except when it's restarted.
The other day I took the remote server off the domain and it took nearly 10 minutes for it to ask for administrator name and pwd to perform the action so I knew it wasn't working properly.  I ran a 500 ping test and had zero loss between sites and the ms return was sub 15 on all 500
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
Do you have multiple DC's in your network topology? If you want your clients to always point to the DC in the main office you need to ensure that it is setup in Sites and Services. The remote subnets need to be added as a subnet in the default site link. This is how AD knows what sites need to authenticate with what particular domain controllers in that site.

Not having this setup properly allow client to try and authenticate to any DC that is available. If you have DC's that are geographically farther away you run into the isuse where people start authenticating to a DC that may be miles away which slows down your authentication process.

On a client that is having issues in the Remote site down the following...
- open cmd
- type set logonserver

This will show you what DC that client is authenticating to. If the latency is too high group polcies will time out after a period of time. I beleive the default is 90 seconds.

Will.
0
 
jonmenefeeAuthor Commented:
That is what I was needing. I will try that in a bit and get back with you.  Thanks!!
0
 
jonmenefeeAuthor Commented:
If I only have one DC, do I put the remote sites in the subnet of Sites and Services?
0
 
jonmenefeeAuthor Commented:
I did the cmd prompt and I added the subnet of the remote site to the AD Sites and Services and I think that did the trick because things are moving much faster (logon was very quick this time... less than 20 seconds vs 5 minutes for other times.

Thanks and I will keep this open for a day or so to confirm.

Oh, before I submit this.  I did not add an RODC to the remote site.  I simply pointed everything back to the Main DC
0
 
Will SzymkowskiSenior Solution ArchitectCommented:
Well if you only have 1 DC then it should not matter because there is only 1 and no other DC's that the users could be authenticating to. That being said, it is a best practice to add your Subnet into sites and services for all physical sites that have different subnets.

On the other note, you said you only have 1 DC in your environment. Well I would add an additional one to this domain as well for redundancy. You could have 2 or even 3 DC's in the main site which will help offsite the load of the single DC. This would also help boost performance as you have 1 DC authenticating many users locally and remotely.

This might be the answer to your issue. If your main office DC is maxed out on resources adding another R/W domain controller should definitly help.

Will.
0
 
jonmenefeeAuthor Commented:
Thanks Will. Right now we are still in beta phase but we will keep an eye on it when we go live. :-)
0
 
jonmenefeeAuthor Commented:
Hello Will

Ok, here is what I have done so far.  I put another DC (writable) in the remote location and made the server in the remote location use the new DC for the Set LogonServer command.  Now, when I open Sites and Services in the Main office, both servers are under the Servers area but nothing (except for the IP address) is in the Subnet area.  Do I need to move the remote DC server to the Subnet that I created or leave it in the Default-First-Name-Site folder?  The Subnet just has an IP address in it and nothing else.

Thanks
PS  the reason I am asking is because there is still a lot of latency in the SQL Management Studio area in the remote site whereas there is no latency in the SQL Management Studio in the main office even though both Servers are physically the same
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 8
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now