?
Solved

Authentication Control Through AD Sites and Services and DNS

Posted on 2005-04-13
6
Medium Priority
?
222 Views
Last Modified: 2010-04-14
I've read several postings on here saying that the only way to control login authentication in Windows 2000 Server is to use the DNS SRV records in DNS that are set up by site and to set priority for what domain controller that site should look to first for authentication.  Our MIS director wants to employ this to keep computers in our various sites from going over wireless links to reach a domain controller (as much as possible).  From other postings I've read, I assume the way to do this is to go to:
      DNS
      (server name)
      Forward Lookup zones
             Active Directory Integrated Zone name
                _ msdcs
                dc
                sites
                Default-First-Site-Name (or other site)
                _tcp
then to pick the SRV record for the DC that should be the first one looked for to authentication, and set the priority.  

What I don't understand I guess is exactly how the priority works.  When I go into the SRV records, each site has records for ldap and kerberos for whatever DC has been put in their site through AD Sites and Services.  I'm assuming that the kerberos records will affect login authentication and the ldap records are for Active Directory lookup (not sure if I'm correct there).  I need to know, if I set the priority to 1 and leave the rest at zero, does that mean the DC that's set at 1 will be looked to first, then any others with zero will be used (in no particular order) if that one's not available? Or, let's say, if I have 5 DC's in one site, I set them at  5, 4, 3, 2, and 1 for priority, does #5 get looked at first, or #1?

Thanks in advance for the help!
.  
0
Comment
Question by:JBurke723
  • 3
  • 3
6 Comments
 
LVL 25

Expert Comment

by:mikeleebrla
ID: 13774781
the way to control this is through networking hardware and/or proper networking subnet setup. Not thru active directory/ DNS at all.  Can you explain your hardware setup.  You say that your ultimate goal is to prevent computers from accessing the DCs over wireless.  do your DCs have wireless cards or something??? even if they do, the DCs wireless cards would "talk" to the access point, not directly from the computer to the DC.  How close are your sites to eachother?  they must be pretty close if they can reach eachother over wireless links.  Again, can you explain your network topology and subnet setup.
0
 

Author Comment

by:JBurke723
ID: 13774961
Basically, our AD Sites are set up one subnet per site.  Each site is a different physical building, 6 sites in all.  Some of them sit fairly close together, such as just down the street.  Others are miles away from our central office (about a 30 minute drive at the most).  I'm not sure I can explain it all in detail, but basically we have antennas on each building that point to the main antenna that then carries wireless signal to the building that houses the main subnet router and the firewall that controlls the internet connection.  This is all done thru use of Cisco Pix firewall routers, Cisco wireless bridges, private IP addressing, and said antennas to turn 6 sites/buildings/subnets into one MAN (metro. area network).

Basically we want each site/subnet to look first to the DC that's a part of their subnet, then look to another one, over the wireless link if that first one is down.  We're trying to avoid slowing down the network by using expensive bandwidth over the wireless links to authenticate user logins.
0
 
LVL 25

Expert Comment

by:mikeleebrla
ID: 13775198
it sounds as though your subnets aren't set up correclty.  say for example you have the following setup:

buildingA    Router-------------------------Router     BuildingB
network: 10.1.0.0                                            network 10.2.0.0
mask: 255.255.0.0                                           mask 255.255.0.0


all of the clients in building A are in a different subnet than building2
all clients in building A should have building A's router set as their gateway
all clients in building B should have building B's router set as their gateway
it sounds as though both building A and B each have their own DC, this DC will of course have an IP address in its range

If you have your sites and site links setup properly in AD sites and services your users will authenticate to the DC in their site first automatically (that is the whole point of setting it up)  There sholdn't be a need to mess with the SRV/DNS records manually.

I dont know what you are trying to do with the SRV and DNS records, they dont have anything to do with different sites if you are running a single domain.  you do just have one domain right?  In that case ALL your DNS servers should have the same records.  Do you have a DNS server at each site?



0
Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

 

Author Comment

by:JBurke723
ID: 13775542
You're correct, we have links set up as such:


buildingA/Cisco PIX 501--------VPN tunnel--------Cisco PIX 501/ BuildingB
network: 10.1.0.0                                            network 10.2.0.0
mask: 255.255.0.0                                           mask 255.255.0.0

and correct, all of the clients in building A are in a different subnet than buildingB and each building/subnet has it's respective PIX firewall router set as it's default gateway and we have several DCs on the network, one in each building/on each subnet and then some.  

So what you're saying is, if there's a DC in one Site, and that's the only DC in that site, that's the only place it should look for authentication?  If you're looking for redundancy, should you have links set up between sites or can you have the same DC in more than one site to make it available if the first one is down?  

Yes, we're just one domain.  All of the DNS servers don't have the same records when I look through DNS.  We have two main DNS servers ( I believe only one of them gets updates from an upstream server).  Most of the DCs are set to point to those two servers for the primary and secondary DNS server settings.  Some of the servers are set to point to themself as the primary DNS and one of the main two DNS servers as the secondary (if that makes sense).

Again, all we're really trying to accomplish, is to have each subnet/site look to it's DC for authentication, but right now, they seem to be looking just to whatever random DC they can contact first.  

I got all the 'stuff' about the DNS SRV records from some other posts on here.  There's a way in the DNS SRV record to set a priority setting.  I got, from a couple of other posts, that it's the setting to control what DC is contacted first when trying to authenticate logins.  I'm interning with this company as a course for my Associate's Degree.  I'm doing research on this and some other issues, and I've been using this forum for one of my main research spots.

Thanks
0
 
LVL 25

Accepted Solution

by:
mikeleebrla earned 2000 total points
ID: 13775701
well if your clients in say siteA are authenticating to the DC in siteB when site A's DC is still up is sounds as though your sites aren't setup properly.  Ideally ALL sites should have their own DC and DNS server (can be the same physical computer of course).  this way if the link goes down between sites, the clients still have a local DNS server to handle DNS queries.  All of the DNS servers should also be AD integrated so they will all have dns records that are the same and integrated with AD. Your problem could be that you clients are looking at a DNS server in a remote site that is also a DC, thus the clients just aurthenticate on the remote DNS/DC.  installing a local DNS/DC would resolve this. All DCs should realy point to themselves for DNS resolution also.
0
 

Author Comment

by:JBurke723
ID: 13776098
I think I see what you're saying.  We did have one server that was sitting in the wrong Site in AD Sites and Services.  I moved it to the right one, so we'll see what happens over the next couple of days . . . I'm going to go ahead and award the points though, cuz I bet it'll work right now! lol

thanks for your help!
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
Good news! Plesk 12.5 (with update #28 and above) now includes support for HTTP/2. This is a major update to HTTP1.1, which is over 15 years old. Read below to learn how to enable HTTP/2 on your Media Temple DV with Plesk.
Look below the covers at a subform control , and the form that is inside it. Explore properties and see how easy it is to aggregate, get statistics, and synchronize results for your data. A Microsoft Access subform is used to show relevant calcul…
Kernel Data Recovery is a renowned Data Recovery solution provider which offers wide range of softwares for both enterprise and home users with its cost-effective solutions. Let's have a quick overview of the journey and data recovery tools range he…
Suggested Courses

615 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question