An essential element of maintaining a secure Active Directory (AD) deployment is tracking log-on and log-off events that both succeed and fail. By tracking this information closely, your IT team will be able to quickly detect a variety of cyber-attack types.
For example, if there is a sudden spike in failed log-on attempts, there is a high likelihood that a brute force attack – one in which a huge number of random passwords are used one after the other to try to gain unauthorized access to your AD deployment – is underway.
Log-on reports are disabled in AD by default. To turn them on, you’ll have to go through a series of steps that begin with opening the Group Policy Management Console (GPMC) by running the gpmc.msc command.
With the GPMC open, you’ll then need to create a new Group Policy Object (GPO) for the specific domain or portion of a domain you’d like to enable log-on auditing for.
Once you’ve created the GPO, you’ll need to go in and edit its properties. To do so, you’ll first need to open the Group Policy Management Editor (GPME). Then, you’ll need to navigate to Computer Configuration > Policies and expand it as follows:
Next, in the right-hand panel of your current GPME, you can either double click on either Audit logon events, or you can right-click and select Properties on Audit logon events.
A new window of Audit logon events properties will open. To enable audit logging of both success and failure for log-in attempts, check the Success and Failure boxes and click Okay.
Finally, run gpupdate /force to update your new GPO.
The above steps will enable audit logging for user log-on attempts, but you will also want to enable audit logging for account log-in attempts, which is a similarly involved, but slightly different process.
As shown above, the process of enabling and accessing user log-on reports is quite involved, and it is only half of the required process for maintaining a full and accurate picture of your AD log-in events.
Moreover, even Microsoft acknowledges that auditing these events directly generates “a lot of noise,” because they happen so frequently and each logon event generates multiple items within the log, which makes it that much harder to glean meaningful information from them.
For example, each logon event can create some combination of the following audit log entries:
A session was reconnected to a Window Station
Click here to read the full comparison of Microsoft vs. CoreView.
CoreView makes it simple to generate all kinds of reports, including logon reports from its intuitive web UI, which provides access to all M365 features through a single pane of glass. Moreover, in order to make these audits effective security tools, they need to be run at regular intervals, so as to keep an up-to-date record of the average number of log-on attempts in a given period of time, which will allow your IT team to recognize unusual spikes in attempted logins.
Perhaps even more importantly, CoreView makes it simple to create automated workflows that can be kicked off by any criteria your IT team designates, which means that in the event of a brute force attack, not only will CoreView allow you to recognize that it is happening in real-time, but it also allows you to have pre-defined steps in place to mitigate any such attempts.
