LDAP traffic across sites

  • Thread starter Thread starter Arjan
  • Start date Start date
A

Arjan

Hi

We have a single domain spread over multiple sites. Each site has it's
own Domain Controller (DC) and this DC is also Global Catalog (GC). At
the main office there are two DCs both GC. Only one DC holds all the
FSMO roles. Beside this we use BIND DNS on Unix to host the dns
domain. Every site has a DNS server. Both clients and server can do
queries to the UNIX DNS. Only a UNIX DHCP server can make changes to
DNS, clients are not allowed to.
This is a domain with Windows 2000 servers (SP4) and Windows XP
clients (SP1).

On at least one site we noticed the following problem:
Most client do LDAP to different DCs on other sites. So far we did not
snif LDAP traffic to the sites DC. however i.m.h.o. LDAP traffic
should not travel across sites since there is a DC on site with a
complete replica of the AD. When XP machine start they use DNS to
discover the closest DC and then log on using this DC. The DC
information is kept in cache so when another proces needs this info
(LDAP e.g.) the information is immediately available

DNS is correct. All DCs are registered correct
Using NLtest we can see the correct DC when querying for the DC on
site
All sites and subnets are ok
Because of an AD integrated application we now have a substantial
amount of LDAP traffic occupiing the WAN when users log on an start
the application. This results in slow WAN traffic for a couple of
ours.

Does anyone know why LDAP travels to other servers
Should LDAP go to the logonserver, discoverd when logging in or is the
discover process for LDAP different
Anyone have the same problem or an explanation for this behaviour?

thanks
 
Could be multiple things.

1. Could be DNS really isn't right even if you think so. However if the clients
are authenticating to the local DC properly, it would seem DNS is right, but
maybe some of the records really aren't, Windows clients don't use LDAP to
authenticate, they use kerberos.

2. Could be your DCs are screwed up and not responding properly.

3. Could be your site/subnet architecture is screwed up.

4. Could be the application is screwed up and not selecting DCs properly.
Honestly, this is my first choice for what you write here since it sounds like
your issues started with this app.

joe
 
Back
Top