Yes, that's the way I understand it. However, I have wondered if maybe this doesn't always work as it should. On the other hand, if others are doing this and not seeing clients crossing sites when they shouldn't, that's good enough for me.
Because our AD has now and always has had just one site, I’m relying on feedback from others who have multiple sites. So far the consensus seems to be that AD clients rarely cross sites when the sites are defined correctly and DNS is clean. If that's true, I'll report to management that it should happen only rarely. Even more importantly, I wanted to hear what others think of relying on a firewall to keep *all* client traffic from crossing sites (DCs would freely communicate across sites). I think it's a bad idea, but I'm going to be pressed for a reason other than the reconfiguration necessary in a disaster scenario. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Brian Desmond Sent: Wednesday, February 8, 2017 9:43 AM To: [email protected] Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site AD will match the most specific subnet so in this case the 10.0.0.0/16 subnet will match anyone who is 10.0.X.X. IP. Thanks, Brian Desmond (w) 312.625.1438 | (c) 312.731.3132 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kurt Buff Sent: Tuesday, February 7, 2017 6:55 PM To: ntsysadm <[email protected]> Subject: Re: [NTSysADM] Blocking AD Client Traffic to a Certain Site And there's your problem, if you didn't typo your response. 10.0.0.0/8 overlaps with (actually includes) 10.0.0.0/16 That's why some clients will go to your second site (AWS) at random. You probably need to list out your subnets more carefully for your main site. Kurt On Tue, Feb 7, 2017 at 11:33 AM, Charles F Sullivan <[email protected]> wrote: > I’ve only been able to do very limited testing. > > > > - I had about 8 member servers in a site which were actually all > in > the same subnet as each of and the one DC we had for testing, let’s > call the subnet 198.168.17.0/24. In that site I included the usual private > ranges: > 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 > > - At AWS I had a subnet with one DC and just a couple of member > servers in the 10.0.0.0/16 subnet, which was defined as the only AWS site. > > Note that the AWS subnet is a subset of one that I defined at the main > site, but this absolutely is supported by MS and others have told me > that this works for them. Despite all of this I did see one member > server in the main site use the AWS DC after a reboot even though the > local DC was clearly present and being used by the other member > servers. So that means 1 out 8 member servers I had for testing > crossed sites. This made me wonder how often it might happen in our > production environment where there are thousands of member computers. > > > > I do have to say that I recently got to test this again, this time > having 5 DCs at the main site and 2 at AWS. Again, I had just a > handful of member servers and a workstation and this time I didn’t see > any of them using an AWS DC. The AWS admin didn’t see his one member > server use anything besides an AWS DC. > > > > From: [email protected] > [mailto:[email protected]] > On Behalf Of Michael B. Smith > Sent: Tuesday, February 7, 2017 1:32 PM > To: [email protected] > Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site > > > > Doesn’t make sense to me. > > > > The only reason you should have cross-site connections at this point > is because you don’t have all of the relevant subnets defined in ADS&S. > > > > From: [email protected] > [mailto:[email protected]] > On Behalf Of Charles F Sullivan > Sent: Tuesday, February 7, 2017 11:40 AM > To: [email protected] > Subject: [NTSysADM] Blocking AD Client Traffic to a Certain Site > > > > I’d like to get some ideas and opinions regarding this, especially if > anyone has had a similar need….. > > > > Our AD topology to this point has been as simple as can be. Since just > about everything on our extended network is connected at high speeds, > we have never had to have more than one AD site. We are about to put a > couple of DCs at AWS, which of course will require a second site to be > defined. This will still be pretty straightforward. Everything but AWS > will be on the one existing site and a second site will be added for the > one subnet at AWS. > > > > I know that even with the two sites defined, some clients may at times > use the remote site. This is what I have seen in testing, for whatever > reason, but I don’t consider it to be a real problem because I assume > it would not happen often. The problem is that our director wants > absolutely no cross-site traffic except in the case of a disaster. > > > > It is being proposed that the firewall between the sites allow only AD > traffic between the DCs themselves. AD clients would be stopped at the > firewall. I’m not comfortable with that as a solution because I’m > concerned that when clients do try to use DCs at the remote site, it > will cause slowness if not failure. Does this seem like a bad idea for > that or any other reason? > > > > I was thinking that maybe I could use weight and priority within SRV > records so that the DCs at AWS would be weight=0 and priority=65535. > If I did that, would the clients at AWS honor the site rules over the > SRV records weight and priority? I’m guess that would be > unpredictable, thus also not a good solution. > > > > Thanks in advance for any help. > > > > > > Charlie Sullivan > > Sr. Windows Systems Administrator > >
