Earlier today, a DC was found at 85-95% CPU. It was also noted that there were
continuous 675 events for one user account:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 4/7/2005
Time: 8:43:49 AM
User: NT AUTHORITY\SYSTEM
Computer: xxxxxxxxx
Description:
Pre-authentication failed:
User Name: yyyyyyy
User ID: zzzz\yyyyyy
Service Name: krbtgt/zzzz
Pre-Authentication Type: 0x2
Failure Code: 0x18
Client Address: a.b.c.d
[We don't really have a user with ID yyyyyy - I have changed names to protect
the innocent :) ]
The users machine was switched off and CPU dropped from 90% to 75% and then
down to the 50% range!
Any ideas how we might explain this behaviour?
Is this an account lockout type issue?
Any help greatly appreciated.
neil
-----Original Message-----
From: Ruston, Neil
Sent: 07 April 2005 08:54
To: # GSI Core Infra EU; # IT GTI GSE Active Directory Team
Subject: FW: [ActiveDir] SLOWWWWWW Logons
FYI
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: 06 April 2005 22:10
To: [email protected]
Subject: RE: [ActiveDir] SLOWWWWWW Logons
Staring a new thread from the original post, as I am going to address this from
a troubleshooting methodology perspective, not a "take a swing and perhaps one
hit out of the park" perspective.
My approach to slow logon:
1) I always start with a userenv log (logging set to 10002). I then take the
log, and begin looking for "gaps" of time in the log, to perhaps understand
components that are being slow during user init.
2) If I don't immediately see an answer in the userenv, or at least a starting
point (can go either way depending upon the case) I go with two pieces of data:
userenv + network trace. Network trace can be tricky, given that you can't take
it on the client....the client hasn't logged on yet. :) Typically, I take the
client machine and throw it on a silly little hub, and on that hub also place
another machine which I take a trace from. Start the trace (some larger buffer,
say 50MB or so), then boot the client + log on to the client, and I don't
usually stop the trace until the logon is complete.
>From there, you can line up gaps of time in the userenv log to what was
going over the wire. I find this approach more fruitful than just taking a
trace and trying to guess where the problem is.
~Eric
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains
and monitors electronic communications sent through its network. Instructions
transmitted over this system are not binding on CSFB until they are confirmed
by us. Message transmission is not guaranteed to be secure.
==============================================================================
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
