Authentication Issue

  • Thread starter Thread starter Jeff
  • Start date Start date
J

Jeff

Our Ad consists of several sites that are geographically dispersed. A user
at our main site is authenticating against a domain controller at a site
several states away. I need to figure out why this is happening? I have
confirmed that the site is configured properly with the correct subnet
object, etc. can anyone direct me how to troubleshoot this?

Thanks,

Jeff
 
Jeff said:
Our Ad consists of several sites that are geographically dispersed. A user
at our main site is authenticating against a domain controller at a site
several states away. I need to figure out why this is happening? I have
confirmed that the site is configured properly with the correct subnet
object, etc. can anyone direct me how to troubleshoot this?
Click to expand...


Most likely -- and first step -- is to make sure each site has the correct
DCs listed within it in AD Sites and Services. If a DC were physically
move or a site creates AFTER the DC was installed there is a good
chance it is in the original site. (Right click\Move will help)

Second thing to check (about as likely but a little more work) is to make
sure that EVERY DC is (ONLY) a client of internal DNS servers that
allow DYNAMIC updates. IF the DC's aren't correctly configured (their
NIC) as clients then they never register themselves in the correct DNS
site "subdomains."

Run DCDiag to insure that all DCs are correctly configured. Capture the
output to a text file; search for FAIL, WARN, ERROR. Fix that or report
here.
 
I've verified that each site has the correct DCs listed. I also verified
that DNS is setup appropriately.

After doing those 2 steps, I ran DCDIAG. Everything checks out OK when I
run dcdiag /e /n:mydomain.com There are no errors listed.

I am in the process of trying to get my hands on the PC that is logging into
the wrong DC. Once I do that I can verify its configuration (IP address,
DNS server, etc.)

Are there any known issues with WinXP logging in to a W2K AD domain?

Thanks,

Jeff
 
Jeff said:
I've verified that each site has the correct DCs listed. I also verified
that DNS is setup appropriately.
Click to expand...

"Appropriately" is pretty vague. What about Sites and Services
sites for each DC?

You know, I didn't explicitly mention it, but also check that every
site has the correct range(s) of IP subnets so that the clients can be
matched up to the DCs -- check this too again when you "get ahold
of the problem client machine."
After doing those 2 steps, I ran DCDIAG. Everything checks out OK when I
run dcdiag /e /n:mydomain.com There are no errors listed.
Click to expand...

I would run it separately on each -- if one of them isn't properly
listed it might get skipped by "running the domain." (After all,
they must be found.) But then that would likely give some kind
of error.
I am in the process of trying to get my hands on the PC that is logging into
the wrong DC. Once I do that I can verify its configuration (IP address,
DNS server, etc.)

Are there any known issues with WinXP logging in to a W2K AD domain?
Click to expand...

Just that it will prefer (or latch onto even) a Win2000+ DC and will stop
using BDCs (by defaulte) but that doesn't seem to be your problem.
 
"Appropriately" is pretty vague. What about Sites and Services
sites for each DC?
Click to expand...

I meant by appropriately that all of the correct service records are listed
in DNS and that name resolution works at each site.

For each physical site there is a site configured in AD S&S. Each AD site
has the correct subnet associated with it. DCs at each physical site are
listed in the correct AD site as well.
I would run it separately on each -- if one of them isn't properly
listed it might get skipped by "running the domain." (After all,
they must be found.) But then that would likely give some kind
of error.
Click to expand...

DCdiag was run on each DC. It did not return any errors and each DC passed
the default tests.

Any other thoughts, suggestions?

thanks,

Jeff
 
Jeff said:
I meant by appropriately that all of the correct service records are listed
in DNS and that name resolution works at each site.
Click to expand...

Ok, and you might run DCDiag to double check.
For each physical site there is a site configured in AD S&S. Each AD site
has the correct subnet associated with it. DCs at each physical site are
listed in the correct AD site as well.
Click to expand...

Good. Those three things are important.
DCdiag was run on each DC. It did not return any errors and each DC passed
the default tests.
Click to expand...

Then likely the DNS error is that the clients are NOT set to the internal
DNS
server (set) OR they are set to it AND a (incorrect) mixture of external
DNS.
 
You said each site has the correct subnet -- I presume that no
site has MULTIPLE subnets or that ALL are listed, right?
 
You said each site has the correct subnet -- I presume that no
site has MULTIPLE subnets or that ALL are listed, right?
Click to expand...

Yes, in the case of multiple subnets, all are listed.

I was able to work with the PC in question and after connecting it to our
LAN in my office, it authenticates against a local DC instead of one at our
remote site. So I am not really able to duplicate what was going on
yesterday.

I guess I need to determine if this is happening to other PCs at our site
and go from there.

Thanks for your help,

Jeff
 
I was able to work with the PC in question and after connecting it to our
LAN in my office, it authenticates against a local DC instead of one at our
remote site. So I am not really able to duplicate what was going on
yesterday.
Click to expand...

One other point -- the following is SUPPOSED to happen (I haven't
really verified this but it is documented clearly):

A PC (laptop) that is authenticating in site "G" and is moved to site "B"
is supposed to INITIALLY try to find the DC(s) in "G" but then that
DC is suppposed to instruct it to "try a B DC" OR if the "G DC" isn't
reachable, the client will go back through the process of finding an
appropriate site/DC.
I guess I need to determine if this is happening to other PCs at our site
and go from there.
Click to expand...

It's might have been a fluke....
 
Herb,

You have it absolutely correct! Laptop will try to find DC in G, which is
then supposed to tell the Laptop, "Hold on. Why don't you contact these
guys who are located in your area ( Site B ). The laptop is then going to
contact 'these guys'. As you said, if a DC / the DCs in G are not
reachable, then the laptop starts at the beginning - hopefully finding the
DCs in B.

Cary
 
Thanks, Herb. That helps. I read in the Distributed Systems guide in the
resource kit about how it works when a PC moves to a different site. Your
clarification helps me understand the process better.

I wonder if it was simply a timing issue? We did not wait long enough for
the laptop to find the appropriate DC?

Thanks again for all your insight.

Jeff
 
I wonder if it was simply a timing issue? We did not wait long enough for
the laptop to find the appropriate DC?
Click to expand...

Maybe -- perhaps the laptop was not restarted when it was moved.
Just unplugged/re-plugged while running, hibernated, or in stand-by.

If the laptop thought it HAD A CONNECTION (secure channel) with
a DC, it might not have "given that up" but just reconnected and kept it
since it worked.

Had it been rebooted then it would have re-stated authentication and
that's likely when it would have received the "go talk to those guys."
 
Back
Top