• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5000
  • Last Modified:

Unexplainable Event ID 675 Flood.

Windows 2003 Domain, 25+ XP Users.

I inherited this domain recently, it had no password security policy enabled, so I did so.

 As soon as I did, certain users began to get locked out immediately.

I proceeded to enable detailed logging, and find my logs flooded with the following:

Pre-authentication failed:
       User Name:      username
       User ID:            DOMAIN\username
       Service Name:      krbtgt/DOMAIN.COM
       Pre-Authentication Type:      0x2
       Failure Code:      0x18
       Client Address:      192.168.1.X


This event is logged by 4 users only, in spurts of 6 events, every 2-3 minutes. Only these 4 users exhibit the failures.

I have gone in, deleted mapped drives, analyzed logons for services, checked for virii, etc.

After hours, the events do not appear. I open files, test applications, log on and off repeatedly, and I do not see these logs.

In practice, every night I attack the issue, and I believe it to be solved; the next morning the issue reappears.

0
Derekleu
Asked:
Derekleu
  • 8
  • 6
  • 5
  • +1
2 Solutions
 
Netman66Commented:
Have you had these users change passwords to meet the new rules you created?

Perhaps these machines are not actually logging in the users but, instead, using cached credentials.

Have you tried these user accounts from a workstation that a user having no issues is using?
0
 
DerekleuAuthor Commented:
Password rules were lifted as soon as users began experiencing lockout issues.

The issue seems to be with the workstation, not the user.
0
 
Netman66Commented:
Yes, that's what I was trying to determine.

Can you rejoin one of those PCs to the domain?

0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
grayeCommented:
Check for scheduled tasks... We often have problems with account lockouts when a user forgets to change his password for a scheduled task.  Unfortunately, the scheduled task could be on *any* PC!
0
 
DerekleuAuthor Commented:
No scheduled tasks whatsoever, no strange authentication accounts for services.

The failure entries happen in spurts of 6, one right after the other (within a minute or two) for every user.

Is there any way to remotely reset the machine account without bothering the user?
0
 
grayeCommented:
So, what was the solution?  (Don't leave us hanging!)
0
 
DerekleuAuthor Commented:
I went on-site earlier today, took the computers off the domain; changed the computer name; and rejoined them to the domain.

Side effect noticed: These 4 computers were not taking group policy updates as they should.  I would really like to know what could cause only these 4 systems to fall off the grid in that way.
 
I will not be able to see the effects of my actions until wednesday.
0
 
Netman66Commented:
I suggested rejoining the domain earlier.

0
 
DerekleuAuthor Commented:
Netman: Do you, in your heart of hearts, believe that your earlier suggestion was worth 500 points?

0
 
Netman66Commented:
No, but that's why there's a grade to select.

Part of the solution was provided to you, so it's reasonable to expect you to at least acknowledge that.

0
 
DerekleuAuthor Commented:
Ok, its Wed. And the event failures are back in full effect!

Pre-authentication failed:
       User Name:      user
       User ID:              DOMAIN\user
       Service Name:      krbtgt/<name removed>
       Pre-Authentication Type:      0x2
       Failure Code:      0x18
       Client Address:      192.168.0.X


These are logged several times a second, for every user, every 2-3 minutes. The same computers.

I scanned them for virii again, took them off the domain, changed their computer names, and then rejoined them to the domain.

I know a reghosting will fix the issue, but I need to know what the cause of this issue is.

0
 
grayeCommented:
If you've got the spirit to continue the fight, here are some suggestions that might help...

Download the Resource Kit from microsoft to get the "Klist" and "Kerbtray" utilities.  Use 'em to display/monitor/clear the Kerberos cache.  There might be some valuable information in there!
0
 
Netman66Commented:
Is that domain name public?  Do you have any clients (including servers) with the ISP DNS server addresses on the NICs?  If so remove them - point everything to your internal DNS servers and rely on Forwarders to get to the internet.

It appears that the clients might be trying to talk to the ISP's DNS server rather than yours.

0
 
grayeCommented:
Huh?  Netman66, are you on the right thread?

The error is from the Kerberos Ticket Granting Ticket service.   The failure code is simply "bad password supplied"

The most likely cause is some errant process on those PCs which are working against a old set of cached credentials.   The problem is that it's practically impossible to determine which process is causing the authenication traffic.  By using some Kerberos "sniffing" tools, you might be able clear the kerberos cache and spot the packets that are causing the problem.  From there, we might be able to deduce which process is the causing the problem.
0
 
DerekleuAuthor Commented:
I have sniffed the packets causing these logs, is there anything that could be done with those?
0
 
grayeCommented:
Is there anything in there that would indicate the source application/process ID?

If not, we can "graduate" to using the Windows tracing tools to capture the processes that are running at the time and match the timecodes with the authentication traffic.  This is a somewhat tedious process and once again, might not yeild any good results.

http://technet2.microsoft.com/WindowsServer/en/Library/6154fafc-a26e-49a2-b590-ed40c54f3f711033.mspx?mfr=true

0
 
DerekleuAuthor Commented:
Event ID: 560

Object Open:
       Object Server:      SC Manager
       Object Type:      SC_MANAGER OBJECT
       Object Name:      ServicesActive
       Handle ID:      -
       Operation ID:      {0,12575680}
       Process ID:      728
       Image File Name:      C:\WINDOWS\system32\services.exe
       Primary User Name:      COMPUTERNAME$
       Primary Domain:      BMP

I checked local event logs, this is the entry that coincides with the server's 675 0x18's. How do I identify Process ID: 728?
0
 
DerekleuAuthor Commented:
I have another:

Event Type:      Failure Audit
Event Source:      Security
Event Category:      Object Access
Event ID:      560
Date:            7/6/2006
Time:            10:20:14 PM
User:            NT AUTHORITY\NETWORK SERVICE
Computer:      SHARVEY
Description:
Object Open:
       Object Server:      SC Manager
       Object Type:      SC_MANAGER OBJECT
       Object Name:      ServicesActive
       Handle ID:      -
       Operation ID:      {0,49638}
       Process ID:      696
       Image File Name:      C:\WINDOWS\system32\services.exe
       Primary User Name:      COMPUTERNAME$
       Primary Domain:      BMP
       Primary Logon ID:      (0x0,0x3E7)
       Client User Name:      NETWORK SERVICE
       Client Domain:      NT AUTHORITY
       Client Logon ID:      (0x0,0x3E4)
       Accesses:            READ_CONTROL
                  Connect to service controller
                  Lock service database for exclusive access
                  
       Privileges:            -

Event ID 696=Services.exe
0
 
grayeCommented:
Well, we're getting closer!

It appears as PID 728 and 696 are trying to interact with the Window's Service Control Manager (like with a service is asked to start, etc).   When services are set to Manual, this type of interaction is normal.  But perhaps in this case the program is using some cached credentials.

If you can "catch it" doing it, you can just use the normal Task Managere to get the Process ID (use the View menu to add the PID column to the display).  Otherwise you can turn on Process Auditing to gather even more tracing information.
0
 
jmpawsonCommented:
This happened to me - I updated the password policy to require capital letter and number.  Accounts which did not come up to the new standard locked out randomly.  Changed password to meet new requirement and all ok.
0

Featured Post

Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

  • 8
  • 6
  • 5
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now