AD to NT4 domain authentication process - why would a client connect to different AD DC's in other S

  • Thread starter Thread starter ed
  • Start date Start date
E

ed

Two Scenario we are experiencing and looking for any advice you might have:

A number of client and member servers in our AD domain are connecting to
different DC's in multiple Sites. We see this through a low level
conversation report on our WAN analyzer. If they were connecting to the
PDC emulator, it would make sense, however these are other DC's. Any ideas?

DC to DC traffic - In the same conversation report, we are seeing DC's
communicating with other DC's that are NOT part of the Site replication
CA's, and are not configured to pull any DNS information as secondaries from
any of those DC's. We do have the _msdcs.xxx.com zone on each DC, for
forest-wide/GC information access, however they are again, not pulling from
those DC's. Any ideas?

Thanks in advance,

Ed
 
[email protected] said:
Two Scenario we are experiencing and looking for any advice you might have:

A number of client and member servers in our AD domain are connecting to
different DC's in multiple Sites. We see this through a low level
conversation report on our WAN analyzer. If they were connecting to the
PDC emulator, it would make sense, however these are other DC's. Any
Click to expand...
ideas?

I presume you mean that clients from one Site are
authenticating to a DC in a another Site?

If so this calls into question your Sites setup.

Do you have the Sites defined in Sites and Services
with the proper Subnets assigned to each AND with
the DCs located in the correct site?

For instance, if you set up sites AFTER the creation
of the DCs and neglected to move them in Sites and
Services from the default site to the proper site you
might actually have DCs with the wrong site, and thus
sites with "no" DC.

You might also have a DNS problem (*see below) wherein
not all DCs are fully/properly registered with DNS. Most
common if it works partially is that some DCs are not
clients of the INTERNAL DNS solely or cannot find the
Primary (or AD-integrated Set of) DNS services which
can accept their registrations using DDNS.

Also, note that you need a GC in each Site -- if you have
only one domain you can make ALL DCs GCs with no
significant downside.
DC to DC traffic - In the same conversation report, we are seeing DC's
communicating with other DC's that are NOT part of the Site replication
Click to expand...

Again it sounds like misconfigured Sites or misplaced
DCs.
CA's, and are not configured to pull any DNS information as secondaries from
any of those DC's.
Click to expand...

That configuration is automatic, you do not normally
control it and the concept of "secondaries" doesn't
exist among Win2000+ DCs.
We do have the _msdcs.xxx.com zone on each DC, for
forest-wide/GC information access, however they are again, not pulling from
those DC's. Any ideas?
Click to expand...

You can look in Sites and Services and SEE the connection
objections created by the KCC -- you might be tempted to
manual adjust this, but your first steps should be to correct
whatever misconfiguation caused the KCC to make incorrect
decisions. (i.e., Sites, Subnets, DC placement in Sites.)

*DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domain (either directly or indirectly)

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /server:DC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
 
Ed,

As Herb mentioned, you would need to make sure that your Sites and Subnets
as defined in your Active Directory Sites and Services are set up and
configured properly.

You also want to make sure that your DHCP Server ( assuming that you are not
using a networking hardware device for this ) is giving the clients the
correct IP Lease ( and the Options as well ).

Now, even if all of this is set up correctly there is a small chance that
your clients in SiteA will still authenticate against a DC in another Site.
This is due to the 'Generic' Records. There is a really excellent article
on this. You have found it ( see your other post ). This should explain
things clearly...

--
Cary W. Shultz
Roanoke, VA 24014
Microsoft Active Directory MVP

http://www.activedirectory-win2000.com
http://www.grouppolicy-win2000.com
 
Back
Top