As an Active Directory expert, I've often been called upon to do some forensics to determine when the last time some disgruntled employee logged on using their account, how many bad logon attempts were made against an account, when was a user added to a group, why an account keeps getting locked out, etc. Out of the box, Microsoft provides one tool for finding this sort of information: the Windows Event Log.
If you've ever done any searching through the event log, especially on Active Directory domain controllers, you know what a miserable experience it can be. The event you're looking for can be extremely hard to find, particularly if you don't know exactly what you're looking for. The event may have occurred on another domain controller, may have occurred a long time ago and is no longer present in the log, or may never have been logged at all.
If you have a security team that is serious about security, they may want you to audit everything: successful logons as well as unsuccessful, object access, privilege use, the works. If you enable all auditing, the event log will fill up so fast with so many events, not only will it be much harder to find anything, but the log size will grow very large, very fast. In most environments, the log size must be limited to a reasonable maximum, which means, if you're logging a lot of events, the log will only hold a short time worth of data. At my last job, the security logs on the Active Directory domain controllers could only store less than 24 hours worth of events. If the event I was searching for happened yesterday, chances were the evidence in the log was gone for good.
Increase the log size? Sure, to a point, but the Windows Event Log is stored as a flat file, so access is slow and gets worse with a larger size. At some point, you have to disable logging of certain types of events, or live with the short event storage time. This is where external change auditing software comes to the rescue.
There are tools such as
Netwrix Change Reporter that collect logs from Active Directory, Windows servers, Microsoft Exchange, SharePoint, VMware, NAS filers and other sources. The idea is to collect the logs and store them centrally, in a relational database, where they can be easily stored and searched, analyzed and reported on, or immediately alerted on.
This type of central event collection system copies important events from the logs almost as soon as they occur, so the length of time the event is stored on the source server no longer matters. In the central repository, the length of time the event may be stored can be much greater, since the relational data store can handle a great deal more data than a flat file.
Once the log data is centrally stored in a database, advanced analytics and search criteria are used to produce useful reports that make it easy to pinpoint the events in question, or to produce comprehensive change audit reports for the entire IT infrastructure. Such reports are invaluable for consumption by your IT security team or for use during periodic inspections by compliance auditors.
To produce such reports by manually collecting individual logs from all of these sources and sifting through this mountain of data would be a monumental undertaking if not just not possible. In the age of ever increasing compliance requirements (SOX, HIPAA, PCI, etc.), you may be compelled to maintain this level of change audit capability. Netwrix Change Reporter makes it possible. You can learn more about Netwrix Change Reporter and download a free trial at:
http://www.netwrix.com/change_auditing_solution.html.
1:16 PM
Brian Seltzer
Here's a free, handy utility that you can use to calculate the properties of an IP subnet. Given an IP Address and a subnet mask, we can calculate the network address, the first and last addresses in the range of addresses that are valid for that subnet, and the broadcast address.
Image icons used on this site are courtesy of Oxygen-icons.org