See http://www.eventid.net/display.asp?eventid=675&eventno=62&source=Security&ph ase=1
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruston, Neil Sent: donderdag 7 april 2005 10:46 To: [email protected] Subject: [ActiveDir] 675 events [Account Logon] Importance: High 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/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. 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/
