Domain login taking loads of attempts

Vertigo

Vertigo

Vertigo

Soldato
Joined
28 Dec 2003
Posts
16,522
Got a really weird problem which seems to strike different users at random times.

When it happens, it takes a huge number of attempts to login to the domain. I just had it myself this morning, took me several minutes and probably 30-40 attempts before I logged in. The password was correct before anyone suggests that - it's just the authentication failed.

Anyone had this or got any ideas?
 
Without knowing your infrastructure it could be a lot of things, NAC, flaky network, but assuming it's multiple PC's/users I think the most likely is a DC problem.

The obvious place to start is to check the event logs on your Domain Controllers for authentication failures, and go from there.
If there are no authentication failures, then it's more suggestive of a network issue, but could also be a DNS issue preventing you from finding the domain controller(s)in the first place.

Start there, but we'd need a great deal more information to give anything other than pointers.
 
It happens to a few users at random, most are unaffected. When it happened to me yesterday I couldn't RDP into any server using my account but other accounts were fine, suggesting it's not the local machine at all but rather the DC.

Fairly basic network with a primary and backup DC (both W2003 and both due for replacement very soon). Had a look in the logs on the DC and there were no failure audits recorded for the numerous attempts this morning.
 
Network card dropped out? Power saving on the NIC? Do you leave your PC on all the time or was it a fresh restart.

Hundreds of reasons to be honest.

I'd upgrade those DC's ASAP though.



M.
 
P.S. If / when it happens again use the local administrator account on your PC and check if you can ping the DC's, etc.

DNS is setup correctly I'm assuming - can you ping your domain when this happens?


M.
 
Vertigo1 said:
Ta for all the suggestions, tbh I'm not sure whether to spend time trying to track it down or just get the DCs replaced pronto.
Click to expand...

i doubt that will help if most users have no issues, check the event logs on workstation and server see why the logins failed?
 
Vertigo1 said:
Ta for all the suggestions, tbh I'm not sure whether to spend time trying to track it down or just get the DCs replaced pronto.
Click to expand...

Though to bring in new DCs you need a healthy AD to start from. If there's a replication issue, you may well struggle to promote the new boxes and just have a bigger mess to try to fix.

If they aren't already installed, get the Server 2003 Support Tools loaded up and start working through the output from tools like DCDiag and RepAdmin to ensure AD is happy.
 
And dig the actual login error out of the event log.

Are all the DNS servers listed at the top of your domain actually valid? Are there any stale DC objects in AD?
 
Well it happened again this morning. Interestingly, the failure audits were on what I consider to be the "backup" DC rather than the primary, although I appreciate the concept of PDC and BDC went out with NT.

The audit was event id 675, "pre-authentication failed" with an error code of 0x19. Googling seems to suggest this might be an encryption issue with Kerberos. Windows 7 obviously defaults to a more recent encryption system than is supported by the 2003 DC but should fall back. Perhaps it's not doing so for some reason? Found a registry setting for the client which is supposed to force it to use compatible encryption, will see if that works.

Regards the DC & AD, yeah I do need to do some checking to make sure it's all actually healthy before migrating to 2012 R2.
 
#Chri5# said:
Though to bring in new DCs you need a healthy AD to start from. If there's a replication issue, you may well struggle to promote the new boxes and just have a bigger mess to try to fix.
Click to expand...

Very, very seriously this.
Rushing the introduction of new DC's would be a very bad idea until you've located the source of your problem and resolved it.


You mention you checked the logs on a DC, but if you haven't already, you need to check all of them - You never know which DC you might connect to for authentication. The Eventcomb tools Gzero linked to are very good for this, particularly with multiple DC's.

If there are no login failure events then it's highly suggestive of a 'network' issue, and I'd be looking at your DNS servers next (Which I'd guess are also your DC's).

#############
heh, got ninja'd!
Doing a bit of googling on that error the users should still authenticate, so though it's suggestive, it may not be your actual problem.

Try filtering that event out from the logs and see if there is anything else to do with authentication failures.
 
Last edited:
The best tool in this case would be wireshark. Install it on client PC with the issue and on DC if possible. You will then see the comms if you try a AD bind using Powershell or something of that nature. You could do it at logon but you would need to remotely wireshark the PC from another pc.

Also you mentioned different authentication levels. So you want to check your NTLM settings in the AD. Ideally you want them set to the same as the client

0 = use LM or NTLM1 only

1 = use NTLM2 if negotiated

2 = use NTLM1 only

3 = use NTLM2 only

4 = Domain Controller refuses LM Authentication

5 = Domain Controller only accepts NTLM2 (refuses LM and NTLM)
 
I've checked both DCs with a full DCDIAG run and no issues reported at all, which is a relief at least! REPADMIN also reports nothing out of whack.
 
Does it lock you out if you enter the wrong password? would indicate if its hitting the DC's at all.
Also if you do echo %logonserver% from a cmd prompt and just make a note to see if its the same one repeats after a few reboots/logins
 
I think there is a hotfix for 03 servers and kerberos authentication issues. I am planning on removing the 03 dc's as soon as i can.

There is a group policy setting that you can enable that will halt processing any GP before the network comes up. There was an issue a while back where the network was starting up after the kerberos auth was occurring to the dc and failing to login.
 
You must log in or register to reply here.
Back
Top Bottom