EventID's 5723 and 5790 but dcdiag is clean?

  • Thread starter Thread starter dxt178
  • Start date Start date
D

dxt178

I am having a very tough issue with one of my DC's at a new remote site
that has me pulling out what remaining hair I have. I have a traveling
user with a winxp pro SP2 laptop that is set to DHCP and this user has
no problems at any other location, but recently has intermittent login
problems at this new location. I am getting event id: 5723 and 5790
errors in the event log for this computer. I removed the computer form
the domain, removed the DHCP lease, removed the computer from AD users
and computers, and rejoined the domain and the computer logged in fine,
got a DHCP lease, and updated DNS properly. The user worked fine for a
few days and then again could not log into the domain again. Each time
I can remove/rejoin the computer and it will log in again, but this is
not acceptable to me or the user.

It would appear that it is DC or trust related, but when I run DCDIAG
it passes fine. Please read the error message for the event ID 5790
below, as it may possibly be a clue... it seems like the DC is missing
the correct event message for event 5790. I did have one other laptop
user travel to this location and they were able to log in fine each
time.

Event ID: 5723
The session setup from the computer <computer name> failed because
there is no trust account in the security database for this computer.
The name of the account referenced in the security database is
<computer name>$.

* Event ID: 5790
The description for Event ID ( 5790 ) in Source ( NETLOGON ) cannot be
found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. The following information is part of the event:
<computername>, Access is denied.

Additional info:
* Today this DC gave me an event ID: 3096

* The routers at each location are set to IGRP as the routing protocol,
however this new location and new cisco router no longer supports IGRP
so it is on a static route back to our main location.

Any and all info is apreciated, hopefully someone can enlighten me or
point out what I am missing.

Thanks!
 
For the quickest test, try removing the laptop from the domain, reboot,
rename the laptop, reboot, rejoin the domain. Test the whole scenario
again.

I'm thinking it may be a problem with mismatched machine accounts.

How many DC's do you have total?
Are they all replicating cleanly?
Is the Windows Firewall enabled on the Laptop?

When you rejoin the domain it syncs the secure channel password between the
laptop and domain.
You can run the SET command to see what the logonserver is when you have a
successful logon and a failure.
See if they're the same DC.

You could also (on the local DC) run the MPS Reports tool that Microsoft has
available at:


This will capture the bulk of the troubleshooting data they would use to
identify the cause of the problem, including the output from a repadmin
/showreps which will indicate what the replication status is for each
replica DC, both inbound and outbound. Maybe one DC is not syncing in a
timely manner and it's causing the mismatch.

It's a start, but we'll need to see more data.


Mike
 
Mike said:
For the quickest test, try removing the laptop from the domain, reboot,
rename the laptop, reboot, rejoin the domain. Test the whole scenario
again.

I'm thinking it may be a problem with mismatched machine accounts.
Click to expand...

I have done this and it does result in her being able to log in, but so
does keeping the computer name the same and simply removing/rejoining
too. Also, this laptop works fine at every other location.
How many DC's do you have total?
Are they all replicating cleanly?
Is the Windows Firewall enabled on the Laptop?
Click to expand...

I have 13 DC's total one at each location.
I believe so, but how can I test this?
No, I have ensured windows firewall is turned off.
When you rejoin the domain it syncs the secure channel password between the
laptop and domain.
You can run the SET command to see what the logonserver is when you have a
successful logon and a failure.
See if they're the same DC.
Click to expand...

Here is the strange part I just found today. Out of the 6 computers at
this location this one and one other are generating Failure Audits in
the Security Event Log quite frequently and in large amounts on the DC.
The Event ID: 676 and the failure code is 0x6. There are tons of them
so it is not actually due to them typing the wrong username/password,
but something else. And the computers are logged into another DC at a
different location which they should not be. I'm wondering if it is
clock time related, or if the DC at this location is not working for
some reason. The strange thing is that DCDIAG passes the whole way down
on this DC.

I have verified that the Site is set up properly in AD, and the subnets
are correct. Why are they not authenticating locally as they should? I
don't believe you can force an authentication server any more so how
can I test this?
You could also (on the local DC) run the MPS Reports tool that Microsoft has
available at:
Click to expand...

Which tool? There are a number of MPS Reports tools: Alliance,
Directory Services (not for Windows NT 4.0), Networking, Clustering,
SQL, Software Update Services, MDAC and
Base/Setup/Storage/Print/Performance.
This will capture the bulk of the troubleshooting data they would use to
identify the cause of the problem, including the output from a repadmin
/showreps which will indicate what the replication status is for each
replica DC, both inbound and outbound. Maybe one DC is not syncing in a
timely manner and it's causing the mismatch.

It's a start, but we'll need to see more data.
Click to expand...

It is a start, and you have given me the most help and hope so far. If
you could please answer some of my questions I will be happy to get you
any and all info I can to try to solve this. I really appreciate the
expertise, Thanks Mike!
 
I replied to you directly via e-mail...

Run the Directory Services version on the DC in the local site with the
problem.
It will show the repadmin output which should show any replication issues,
as well as relevant entries in the event log to help identify any other
related events.

Check your e-mail for my reply.

Mike Shepperd
Sunfire Solutions LLC
Seattle, Washington
 
Back
Top