Authentication auditing is an essential part of protecting Windows computers from intrusion. The big problem in Windows auditing is trying to understand what’s going on, without drowning in a flood of irrelevant or useless information. If you let it do so, Windows 2000 will bury you in event notifications. Figuring out what’s going on from those notifications can be a real chore. In this Informit.com article, Rick Cook provides specific suggestions to start making your auditing process more informative.
(from the article) Event 675 isn’t usually a security problem, but it will drive your users nuts. If the user’s clock is more than five minutes off (default) from the authenticating system’s clock, the authentication will fail. Log 675 events and reset the user’s clock.
Isn’t syncing to a time server a default and automatic process? It should happen as part of the initial login attempt if not before hand.
Funny – I see these all the time and we do have time sync working perfectly – the end users never see a thing – they get in just fine. I also see this regularly from my authenticating squid server (Linux). I haven’t figured out the issue there (it uses ntlm authorization for executable downloads), but it works fine anyway.
On another note, the article was pretty light. I’ve been working with SEC to parse logs for auditing purposes and am forwarding windows events to a syslog server for parsing. I was hoping to get insight as to how to pickup real login attempts vs the regular chatter caused by things like SQL Enterprise Manager. But this was just a listing of some event ids and their meaning – not much new stuff.
On another note, the article was pretty light. I’ve been working with SEC to parse logs for auditing purposes and am forwarding windows events to a syslog server for parsing. I was hoping to get insight as to how to pickup real login attempts vs the regular chatter caused by things like SQL Enterprise Manager. But this was just a listing of some event ids and their meaning – not much new stuff.
Re: ‘article was pretty light’; I agree.
There’s always pipe and filter commands, though that assumes that a legitimate attack can be boiled down to specific triggers.
I’m partial to the tactic of ‘lock down the servers, treat the lan like the internet, and consider everything not under your exclusive control to be hostile’. In short; Ignore what you can’t control, and control the hell out of everything else. Reasonable people can call me crazy or misinformed. Comments appreciated.
This really is the only strategy that works. Trying to make sense of Windows is impossible without the source code.
Just what the hell are you talking about? Having the source code has no connection to anything to do with this article whatsoever. Go back and tinker with your Linux, hippie.
Thousands of contradictory and fluffy tech notes later… you will understand that how Windows works is woefully underdocumented, misdocumented, and undocumented.
Then you will understand that if you want to see why something is screwed up, you need to read the source. It saves time and energy.
What does wanting to understand something have to do with being a “hippie”?? Is it time for some recycled class warfare?? Hippies vs. fascist industrialists, is it??
Or is exclaming “hippie!” Microsoft’s stupid response to *anyone* who is not an ardent fan of their uber-crappy software??
heh….. i only use linux but…. heh.. i gotta say this comment is pretty funny ” Go back and tinker with your Linux, hippie”… hehe, had to laugh when i read that
reminds me of a southpark episode lol.
“Hippies piss me off”…. eric cartman
hehehe
Instead of auditing it’s way better to make sure nobody can’t connect who is supposed to stay out in the first place.
Have a look at:http://www.eeye.com/html/research/upcoming/index.html
There’s a serious vulnerabillity in win2000,win2003 and MS is allready 68 days overdue with a adequate solution.In what way does auditing help you to prevent crackers from exploiting the vulnerabillity.Who says the logs aren’t tampered with?