Derekleu
asked on
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.
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.
ASKER
Password rules were lifted as soon as users began experiencing lockout issues.
The issue seems to be with the workstation, not the user.
The issue seems to be with the workstation, not the user.
Yes, that's what I was trying to determine.
Can you rejoin one of those PCs to the domain?
Can you rejoin one of those PCs to the domain?
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!
ASKER
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?
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?
So, what was the solution? (Don't leave us hanging!)
ASKER
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.
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.
I suggested rejoining the domain earlier.
ASKER
Netman: Do you, in your heart of hearts, believe that your earlier suggestion was worth 500 points?
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.
Part of the solution was provided to you, so it's reasonable to expect you to at least acknowledge that.
ASKER
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.
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.
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!
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!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
I have sniffed the packets causing these logs, is there anything that could be done with those?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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\servic
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?
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\servic
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?
ASKER
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\servic
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
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\servic
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
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.
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.
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.
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?