Sorry - just to be absolutely clear, my response is meant only to apply computers with addresses in that 10.0.0.0/16 subnet. Machines in other subnets would talk according to the other definitions in ADS&S.
Kurt On Wed, Feb 8, 2017 at 10:17 AM, Kurt Buff <[email protected]> wrote: > Right. > > So if his off-prem site is 10.0.0.0/16, and his on-prem site is > 10.0.0.0/8, then his on-prem computers in the 10.0.0.0/16 defined > subnet(s) (i.e., from 10.0.0.1-10.0.255.254) will go off-prem, since > the on-prem site definition is less specific than the off-prem > definition. > > So, like i said, he needs to fix that, if he doesn't want his on-prem > computers to talk to the off-prem DCs. > > amirite? > > Kurt > > On Wed, Feb 8, 2017 at 6:43 AM, Brian Desmond <[email protected]> wrote: >> 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 >>> >>> >> >>
