Link to home
Start Free TrialLog in
Avatar of jpeterson-ee
jpeterson-eeFlag for United States of America

asked on

Vista clients generate numerous 675 events on Windows 2003 DC

I have two Vista machines in my domain.  The domain controller is a SBS 2003 box with SP2 installed. I was finding numerous failure audits of various types in my security event log.  I traced and fixed 95% of them which were the result of problems with W32time.  Now none of the xp machines gernerate events, but the two Vista clients generate numerous 675 events with a failure code of 0x19.  I did create the group policy for vista machines that microsoft provided.  The errors seem to occure when the computers are in sleep mode.  When I come and check the logs in the morning, it's filled with them.  During the day it happens occasionaly, but I think during a rebot etc...  I turned one machine off over night and it did not generate any errors.  The one left on or perhaps sleeping, did.  It's  always in groups of 4 quick events and then a random gap of time.  I would ignore the events or turn off the logging, but I have been a victim of attacks as of late so I need to scan the logs every day looking for intruders.  It's much easier to do with out a bunch of events that clutter up the log.  I have done extensive internet searches and have not found anything that works. Any help would be most appreciated.
ASKER CERTIFIED SOLUTION
Avatar of tenaj-207
tenaj-207
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jpeterson-ee

ASKER

Hey thanks for the reply!

I checked the settings for both vista machines and they were already set as you suggested.  I changed my machine to a workgroup, restarted, then rejoined the domain and restarted.  I did tests with restarts on my machine and an XP machine.  Mine throughs a group of 675 errors once the PRESS CTRL ALT DEL TO LOGON screen appears.  Once I supply my password, one more event appears.  On the XP machine, no events are generated.  In the same article you linked me to, I looked for a flag that was suggested in an other article I read. They suggested changing the DONT_REQUIRE_PREAUTH flag.  This flag does not exist on any of my computer or user objects.  Also, if I change my screen saver to require a password a 675 event is generated.  Hope that helps you all narrow down the problem.
I failed to mention that you need to rename the computer after taking it off the domain. So...

Remove the machine from the domain, reboot, rename the machine, reboot, join the PC back to the server, reboot. Then retest.
To be clear, when I rejoin the computer to the domain, it will be undere the new computer name?  And am rejoining the domain manually or am I using the ConnectComputer wizzard through SBS.
Yes new name is good.  And yes do it manually.

Good clarification.

Huh?  Why manually?  You shouldn't ever join a workstation to an SBS domain manually.

Anyhow... jpeterson-ee... is http://support.microsoft.com/kb/926505 installed on your SBS?

If it is, then please post a COMPLETE ipconfig /all from both server and Vista client.

Jeff
TechSoEasy
>>Huh?  Why manually?  You shouldn't ever join a workstation to an SBS domain manually.<<

If the wizard is missconfigured or corrupted, which it sounds like it might be, then doing it manually isn't  a bad idea.  Since there is an issue here and using the wizard didn't help, then doing it manually clears the possibility that there might be something wrong with the wizard.

Am I mistaken in my logic?


I think so... the wizard can't become misconfigured, or if it somehow became corrupted (unlikely), then it wouldn't work on the XP machines and in that case there is a way to restore the wizard. Not using it prevents client machines from gaining the full manageability offered by SBS, so manual ads should be avoided unless you know how to enable all the things that connectcomputer does. (see http://sbsurl.com/connect for a listing)

Then, because a 675 error would often indicate a DNS problem, that would be a good place to start.

Jeff
TechSoEasy
TechSoEasy,

Perhaps I'm mistaken, I have been before, but I still think it's worth trying my suggestion.  And though the wizards in SBS are great and can perform a number of tasks with a click of a button, sometimes I still find myself doing things manually.  Additionally I'm not the only one that sometimes does things the manual way.
http://msmvps.com/blogs/bradley/archive/2008/03/14/connectcomputer.aspx

Perhaps we can agree to disagree on this.

Getting back to the core issue though, if this was a DNS issue why wouldn't it be effecting more clients, instead of just vista?

And jpeterson-ee, I still think you should try my suggestion above regarding removing the PC from the domain changing the name and then re-adding it manually.  The worst thing that can happen is that it wouldn't work you may have to do it again with the wizard and then I'll have to hear an, "I told you so from TechSoEasy." *tenaj smiles*
That post was back in March before Vista SP1 and before a couple of other SBS patches.  Plus I fully disagree about those who commented saying that connectcomputer is useless.  

If he is going to rejoin the domain then the steps to do that are outlined here:  http://sbsurl.com/rejoin (my blog)

Jeff
TechSoEasy
Thanks all for your comments.  I will try to do it manually and then check the logs.  I will then disjoin and rejoin using the wizzard and see if there is any difference.  I'll take a look at the articles you provided links for first.  I'll post my results later this morning.  I just wanted you to know I'm still working on it and appreciate all of your help.

JP
Jeff,

That KB was installed in 2007.  I opened the link however and there are a lot of additional updates listed along with it.  Some of which don't ring a bell.  I'm going to go through the list and make sure they are all installed.
Thanks for your help,

JP
Okay, I changed over to a workgroup and then rejoined the domain manually under a different name.  A restart stilll triggers 10 events as described before.  So now I'm back in the domain under the original computer name with the same predictable results.  I did check all the updates under 926505 and I had indeed installed all the required patches.  One of you mentioned thoughts about DNS problems being a source of the problem.  I had seen some thoughts on this before as well.  I have one XP machine that has trouble with the autmatic certificate request. It throws an event 53 into the Application log saying that the certivicate services denied the requies because the DNS name does not exist for that computer.  Well that computer is an XP box as mentioned before and it is listed in the forward and reverse lookup zones properly in the DNS server.  I'm not looking for help resolving this issue, but am including it as gerneral info about what is happening on my server as it pertains to DNS>
As Jeff suggested earlier, go ahead and "please post a COMPLETE ipconfig /all from both server and Vista client."
Oops.  Sorry Forgot.  See attached files
vista.txt
server.txt
I would suspect that using a public gateway IP on your SBS is to blame for this.  My level of knowledge in routing issues though isn't very high, but from what I know this can cause a problem.  Generally I would never attach an SBS directly to the Internet.  You are much better off putting a router between the SBS and your Internet connection.

Jeff
TechSoEasy
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I too am hesitant to apply this solution, but I cannot find any sources on the web to discourage it.  I think it would be a bad idea to disable pre-authentication for a user account because it would provide more hacking opportunites, but for a computer account in a situation where I am not concerned about attacks from within the company, I can't see the downside.  I'm inclined to accept this as the solution unless someone can give me a good reason not to.  I gave it a try and the errors dissapeared.  Also a success audit is logged showing "Don't Require Preauth' - Enabled" for the computer account.  So at least you get confirmation you put the correct number in.
Another option you could test is to try installing Vista SP2 beta.  Of course you'll want to run a full backup of Vista before you do so.  But, perhaps they've fixed this with the next SP.
Well, my securtity even log was littered with numerous 675 events again from one of the vista clients.  Also a few errors from some xp clients, but those were 673 errors.  My computer did not create any errors.  I did reboot my computer after I changed the attribute, but I don't think the other computer did, and he probably did not log off and went straight into the sleep mode.  I'll make sure he reboots today and I'll post the results tomorrow.  
Well the reboot did nothing.  Still pleanty of events.  The only thing different about hiis machine is that I have not done the disjoin and join opperation to the domain.  I'll give that a try and post the results.  Probably on Monday but perhaps later today.  Still, this feels like were putting a bandaid on an underlying problem.
Please review this thread:  http:Q_23044385.html

Jeff
TechSoEasy
I wish there was an easy solution to this but there is no checkbox or drop down that you can use to easily fix this.  I understand your concern about implementing the change.  If it was me, and I had just been hacked into I don't know what I would do either, maybe a fresh install.  If you do plan on going ahead with the computer and changing the computer name and rejoining it to the domain let us know if it works.

Good luck to you.

@TechSoEasy I already referenced that link earlier, see post ID:23126973, dated 12.08.2008.


Things are a little better this morning.  Only five 675 errors from the other vista client and four 673 errors.  Much better.  I'm not sure what caused these errors, but I noticed that my machine had made one 675 event the other day and I was able to find a coresponding event in my computer applicaton log that matched.  The ISA client had attemted to authenticate and it failed.  I don't think this was the case for the events before because I had gone through the logs on my machine to look for events that matched the time on the server and found none.  So some stray events can be attributed to the ISA client but not the bulk.  I'll keep an eye on things and dig a bit more this week and then put this to bed.  
Thanks for the update, it is appreciated.
I guess we should have asked if you were using ISA Server.  So I assume you are?  Please make sure that you have installed/updated all items listed here:  http://support.microsoft.com/kb/926505

Jeff
TechSoEasy
Yup, I installed all those prior to adding the vista clients. 98% percent of the errors were not generated by ISA, but I found a couple that were and included them to show that preauthentication from any source seams to fail.  The error logs looked good again this morning.  I"m on a deadline today so I can't do the final testing until sometime tomorrow.  I think that the main objective has been reached which was to reduce the clutter in the event log so I could see intrusion attempts quicker.   I'll put this to bed tomorrow some time.  
Howdy all,

Sorry I've been a bit busy as of late, but I am happy to report a very tidy event log.  So I will consider the workaround as a solution.  To stop these errors, one must change the vista computer to be a part of a workgroup, restart, and then rejoin to the domain.  You do not need to change the computer name or rerun the SBS wizzard to connect the computer.  The other step is to change the DONT_REQ_PREAUTH setting as described.  These two steps combined solved the problem.  Thank you all for your help.  Hopefully SP2 will fix this issue for others.
The errors came back in force.  Still just on the one pesky Vista machine.  Mine is still okay.  I will post if I discover any new information.  
Have you found anything new?
Hi Tenaj,

Not yet.  It has been on and off.  No errors for that past 5 or 6 days.  The few days before that, an error every couple of minutes.  Thanks for checkin in.
Had a bad log the other day.  43,000 failure audits in the log.  That hasn't happened again, but I'm still getting failures from that client, and now some from mine again.  An XP client has creeped into the mix.  I'm looking into some exchange issues.  Found coresponding authintication sucesses on the vista machine for exchangerfr and exchangeab.  These were at the same time as the pre-auth errors in the server log.  Fpund Article ID: 927612 and went throught the steps.  No help.  I'm also looking into SearchProtocolHost.exe.  
How often do you have "bod log days?"  Do they happen at the same time of day?  Do they occur during logon/logoff?  Could they correspond with Windows Updates, AV update/scans, or some other background process?
The timing is strange.  Yesterday the log was clean utnil about 2:30 and then the computer generated errors for a few errors.  He doesn't remember what he was doing and the logs show nothing.  Windows update could have something to do with it.  I'll look into that.  I'm hoping at the end of the day it is something simple and stupid.  I'll double check to see if there are any scheduled tasks.  There was only the one nightmare bad log day. A regular bad log day with about 100 from that computer is a few times a week, but not every day.  
Checking the scheduled tasks is a good idea.  Also keep a log of what machines had what errors on what days at what time for how long and what the users were doing at those times that it happened.

To review, log the following;
Day
Time
Duration
Error
What the user was doing
Tenaj,

I had 8000 errors yesterday.  I found the culprit for 7900 of them.  It was stupid Adobe!  It was trying to get updates in the background constantly when the computer is idle.  It asks for a proxy password once but never prompts you for it again even though it keeps getting errors.  It was of course an old password as they change quite often.  I updated the stupid software and then turrned off the automantic checking.  

For the other errors, the ISA log shows a corresponding group of entries to the error in the windows security log.  It's always a group of 4 RPC entires.  The port sequence is the same: 135, 1103, 1103, 1026.  The source ports vary but one is 53036  There is always one error which is FWX_E_ABORTIVE_SHUTDOWN.  I'm looking into that now.
I've been able to pinpoint the error in the isa log to the event log.  It is always TCP port 1100, PRC (all interfaces) protocol, and it always has the result code 0x80074e21 FWX_E_ABORTIVE_SHUTDON
Portqry on 1000 for that machine returns unknown service and filtered which is what you get when you query any port that you guess at.  
Perhaps it would help to find what program is causing this.

You could setup a batch file to run;
netstat -ano >> c:\NetstatFile.txt
taslklist >> c:\tasklist.txt
and then put it in the scheduled tasks to run every 5 min.  Then when you have the error message you can go to the logs and find the corresponding port with netstat, and netstat also gives you the PID, then lookup that PID in the tasklist to find the process that's causing it.
outstanding idea!
I haven't forgot about this issue.  I had a major server meltdown and had to rebuild it.  Things were quiet and I was hoping the fresh system would resolve the issue.  It did for awhile, but now the errors are appearing again.  I created the batch file and was running it before the crash.  I'll be looking at it again next week and all add any usefull infor I find.
Sounds good.
Any update on this issue?
Actually I have been very busy these days, which is a good thing.  The errors are still there but not the mega list anymore.  Still get about 6 errors for each vista client whent the loggon.  We have asked everyone to power down their computers overnight to save a little money.  So the logs aren't too bad in the morning.  I've been having a replication error that has been taking up my free time, but I haven't given up on this one yet.  Keep in mind it is esentially a new server now and a new domain.  Everthing fresh.  Reset the do not require pre auth attribute but that didn't really make much of a difference.  I was hoping a fresh server install would kill the issue but alas it did not.  I will post if anything changes.  I'm it will rear it's ugly head again in the future.  For now I don't have much choice but to accept that it is a problem.  Thanks for checking in!