Windows server 2008 security audit log

Learn More ». Get answers from your peers along with millions of IT pros who visit Spiceworks. Hi Dears I'm dealing with a bad situation that a lot of login attempts coming to my server and hopefully by now all of them failed , but we are on a very dangerous situation. Any idea about this log? Do they look normal?

Best Answer. Reactive solution is to block those IP's as you see them. Proactive - get a list of IPs that your clients use, and block everything at the firewall level except for the client IP's This is not an elegant solution, just a stop gap until you can get a better one in place. View this "Best Answer" in the replies below ». Link to an article explaining Logon Type Looks like the event you show is type 3 which is on the network, so an authenticated user accessing a share possibly.

Bob Apr 25, at UTC. As you've already explained, you have a lot of issues to tackle here Dan Apr 25, at UTC. EchoV17 wrote: The logon type can help determine what its going on.

Hi Echo Thanks for your reply. So logon type 3 couldn't be RDP? Bob wrote: Those are the machine accounts, and if they are failing it just means you have some digging to do as to why. Hi Bob Thanks for the answer Actually there is no logon failure for the machine accounts. The other failed log on attempts are made as logon type 3 , with different usernames, mostly first names, like the one I posted above in reply of "Echo" Please let me know your idea Best.

Doing those two things might be of some help. Bob wrote: If those failed logins are not recognizable users from your internal network, then you have some rather serious security issues to deal with. Thanks for the reply. Also I might be able to do server configurations as well, please let me know your ideas. EchoV17 wrote: Reactive solution is to block those IP's as you see them.

The 9 Categories of events are further divided into 50 sub-categories. Instead of using the GPMC, you have to use a command line tool if you want to configure the more granular sub-categories. That means 50 more decisions to make when determining what to audit.

We'll provide some practical guidance as to what you should audit. So we're left with other methods of event log management. Not a bad thing really as we've always advocated consolidating the data from event logs in one central location.

In addition, while most of the security policy settings remain, a few settings have been added that can have dramatic changes in logging behavior. These can really be annoying both for auditors and administrators. We'll give you the tips to effectively manage these changes. Both the security settings and log information are also found on our new WinSecWiki.

Due to a change to XML format, event logs can actually be read by humans sort of. Microsoft has included more help in understanding events and the impact of changing certain security settings. Some of this is right in the event and some gives a link to more information in Technet. The documentation still leaves a lot of room for improvement so we'll help fill in the gaps for you.

As usual, the real world differs significantly from what was supposed to happen. In Chapter 2, I'll introduce you to the Windows audit policy including the relationship between audit polices and audit categories , the new Microsoft Management Console MMC Event Viewer for Server , and the format of security events. I'll talk about how you can use the new sub-categories to fine-tune your audit policy and make sure you're actually getting the events you want.

Even if you're an experienced Windows Server administrator, I recommend at least scanning this chapter. I've included a few valuable nuggets that might well be new to you.

If you enable a global policy in a GPO, this turns on all the corresponding subcategories. You can use the auditpol. The example below shows how to list subcategories for the Directory Service Access global policy.

If you use:. Directory Service DS Access is more interesting than some of the other audit categories because of the Directory Service Changes subcategory. Many of the categories simply record that a change has been made, along with information about the date, time and security principal under which the operation was performed.

The Directory Service Changes subcategory logs the current and previous value of a modified attribute. This can be useful for troubleshooting and rolling back unwanted changes.

But if Directory Service Changes success-auditing is enabled, two entries are written to the log: one giving details of the deleted attribute value and another with details of the new. If an object is moved to a different location in the same domain, the new and old locations are logged.

All of the configuration examples in this article should be carried out on a domain controller in a test environment. Assign a new name and then open Event Viewer, also under Administrative Tools, and in the left-hand pane expand Windows Logs and click Security. For contrast, create a new AD site. Name the new site, select any site link and click OK. So why does DS auditing log some changes but not others? Simply because default SACLs, either on existing or new site objects, audit for deletion and creation but not for renaming.

In the Properties dialog, select the Security tab and click Advanced. Select the Auditing tab and click Add. Figure 2.