rcurls
asked on
Limit AD authenticating servers
This issue is not for the faint of heart, All right AD experts heres the problem
We are setting up a large scale active directory domain, we will have over 1000 seperate sites all with 2003 domain controllers replicating to brigehead domain controllers in our main office. We are at the begining of this implementation, we currently have setup
3 root level domain controllers (global catalogs)
8 bridgehead domain controllers (global catalogs also)(4 sites with 2 DC's in each site) these are used for AD replication (i know you don't need this many however we are also using these servers as AV repositories so we can push dat files out to all of our offices)
10 remote office up and running on this domain model each with a windows 2003 DC (setup to do universal group membership cacheing)
all the offices are setup as their own site, there are site links between the remote sites and the applicable brigehead site at the main office (determined by the time zone the office is in)The site links cost for all the remote offices are set to 100 with a replication interval of 180 minutes. They are replicating AD partitions with 1 of their respected bridge heads (this is working fine)
All offices are connected to the main office in a hub and spoke topology (not fully meshed) using VPN connections over DSL / broadband. The VPN concentrator is then connected into our core router...all servers in main office live on seperate switches wich connect back to core router also
we are running into an issue were user in office A will log in fine and work for a few hours then all of a suden they will try to authenticate against the DC in office B rather than trying to hit the DCs in the main office, or in our testing we are also finding that if the server at the site is unavailable sometimes the workstation will authenticate against the DC's at the main office and other times it will authenticate against a DC in another remote office. Does anyone have any ideas as to a way to limit the DC a workstation can authenticate against, or why it might think it is a quicker connection going back out to the remote office...
We are setting up a large scale active directory domain, we will have over 1000 seperate sites all with 2003 domain controllers replicating to brigehead domain controllers in our main office. We are at the begining of this implementation, we currently have setup
3 root level domain controllers (global catalogs)
8 bridgehead domain controllers (global catalogs also)(4 sites with 2 DC's in each site) these are used for AD replication (i know you don't need this many however we are also using these servers as AV repositories so we can push dat files out to all of our offices)
10 remote office up and running on this domain model each with a windows 2003 DC (setup to do universal group membership cacheing)
all the offices are setup as their own site, there are site links between the remote sites and the applicable brigehead site at the main office (determined by the time zone the office is in)The site links cost for all the remote offices are set to 100 with a replication interval of 180 minutes. They are replicating AD partitions with 1 of their respected bridge heads (this is working fine)
All offices are connected to the main office in a hub and spoke topology (not fully meshed) using VPN connections over DSL / broadband. The VPN concentrator is then connected into our core router...all servers in main office live on seperate switches wich connect back to core router also
we are running into an issue were user in office A will log in fine and work for a few hours then all of a suden they will try to authenticate against the DC in office B rather than trying to hit the DCs in the main office, or in our testing we are also finding that if the server at the site is unavailable sometimes the workstation will authenticate against the DC's at the main office and other times it will authenticate against a DC in another remote office. Does anyone have any ideas as to a way to limit the DC a workstation can authenticate against, or why it might think it is a quicker connection going back out to the remote office...
hmmm i am dubious on your use of bridgehead servers if everyone has DSL connections....Bridgeheads
Something a little more obvious though - you have defined sites but have you assigned subnets to them? that would explain the cross site authentication attempts
Something a little more obvious though - you have defined sites but have you assigned subnets to them? that would explain the cross site authentication attempts
ASKER
yes every site has its own assigned subnet, we setup the bridgeheads as a way to limit AD replication, without destinguishing the bridgehead in a site with multiple dcs all DCs will replicate to all other DCs that the particutlar site has a site link to (thats a tounge twister). We also have a few sites that connect via 56K frame relay circuits (not exactly great for AD replication).
Chris I like your thoughts on this, I'll have to set it up in our lab environment and let you know the results
Chris I like your thoughts on this, I'll have to set it up in our lab environment and let you know the results
Great okay, please let me know how you get on. I'd be very interested in the results either way.
Chris
ah the slow links justify it then
ASKER
Chris,
we tested this by setting the _ldap , _kerberos, and _kpassword SRV records of one domain controller to have a weight of 1000 forced replication, verified that the remote end had updated its DNS records. We still found the machine to authenticate against other domain controllers.
we tested this by setting the _ldap , _kerberos, and _kpassword SRV records of one domain controller to have a weight of 1000 forced replication, verified that the remote end had updated its DNS records. We still found the machine to authenticate against other domain controllers.
Well that's that out of the window. I'm afraid I can't bring anything else to this. I'll pop a link to this one on the notification thread to see if anyone else can help out.
If Jay is still monitoring this one perhaps we could ask Netman and oBdA to visit? Not sure who else may be able to help.
Chris
You state there is a DC in each of these sites.
Are these DCs also GCs and DNS servers?
If they are DNS servers, do they have a copy of _msdcs.domain.com?
Can you identify the site specifically in the local DNS server?
You are ensuring that ALL sites use completely different subnets and there are no overlaps in ranges - correct?
Are these DCs also GCs and DNS servers?
If they are DNS servers, do they have a copy of _msdcs.domain.com?
Can you identify the site specifically in the local DNS server?
You are ensuring that ALL sites use completely different subnets and there are no overlaps in ranges - correct?
ASKER
All DC's are DNS servers, using ADI DNS, no they are not GC's.
All DCs do have a copy of _msdcs.domain.com however under _msdcs.domain.com under dc under sites some sites _tcp listing have SRV records for just DCs in its site and others have SRV's for DCs in its site and DCs in alternate sites as well.
yes I see a all of my remote sites under _msdcs.domain.com
all sites have completly different subnets with the exception of the default first site which has multiple subnets in associated with its site.
All DCs do have a copy of _msdcs.domain.com however under _msdcs.domain.com under dc under sites some sites _tcp listing have SRV records for just DCs in its site and others have SRV's for DCs in its site and DCs in alternate sites as well.
yes I see a all of my remote sites under _msdcs.domain.com
all sites have completly different subnets with the exception of the default first site which has multiple subnets in associated with its site.
OK, I would make the remote DCs Global Catalogs. Replication isn't going to cause any ill-effects.
As for why some site entries in DNS are inconsistent - that needs to be investigated. The _msdcs zone should replicate completely with "All DNS servers in the Forest" - so they should all be the same.
As long as the main site does not have any subnets that belong to other remote sites associated with it, then all is well in that area.
As for why some site entries in DNS are inconsistent - that needs to be investigated. The _msdcs zone should replicate completely with "All DNS servers in the Forest" - so they should all be the same.
As long as the main site does not have any subnets that belong to other remote sites associated with it, then all is well in that area.
I should add, what is likely happening (since you are using Uninversal Group caching) is that TTL for users is expiring and they have to go out to a GC to get authenticated.
Unless your domain is in Native mode the UG caching is pretty much useless.
I think once the remote DCs are GCs then this should iron itself out with the help of KCC.
Unless your domain is in Native mode the UG caching is pretty much useless.
I think once the remote DCs are GCs then this should iron itself out with the help of KCC.
If no comment, then I will delete - refund this on my next pass.
Keith
Keith
I think there is enough info here to PAQ. The answer was likely provided, but we need to hear for sure.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I can't find any particularly useful documentation on this so this is all conjecture really. If you have a test network available it would be interesting to try out a few things.
The logon process is, as you're probably already aware, run by the LSA (Local Security Authority) Service. I believe that it must, as part of the logon, perform a DNS Request for the Service Records associated with _Kerberos for that particular site. i.e.:
_kerberos._tcp.<SiteName>.
I suspect that if it fails that request it attempts a slightly different request, probably for:
_kerberos._tcp.yourdomain.
I need a bigger network to check, but I can't log into one at the moment. Anyway, that should return pretty much every DC within your domain. You may find you have to modify that service record query to be dc._msdcs.domain.com rather than just domain.com, but this is more for illustrative purposes.
The point here is that you should notice that each of those is equally weighted, and has equal priority. That suggests that the LSA Service will just pick the first one it sees as appropriate. A type of load balancing is involved as well.
If that is the case, it should be possible to slightly increase the Priority of a the main site server so that the client will prefer to use the main office's servers should their sites not be available. These priorities work in exactly the same way as MX priorities do, the client will pick the lowest available.
As well as this you have Weight, this allows you to further break down this. So you can set some serfers with equal priority, yet still prefer the client to use one above the others. In this case the highest weight is choosen.
All well and good, but it's entirely possibe that the DCs ability to Dynamically Update it's own records might still mess this up completely.
Any thoughts? Hopefully someone that knows more can help as well.
Chris