If a large number of failed logon attempts occur within a certain period of time it could be an indication of a security threat, which is why it is important that organizations have a pro-active means of auditing and monitoring whenever this happens. There are a number of ways you can perform this audit, one of which is using the native tools. Here we will take you through the steps so that you know how to perform this audit when required:
Solution
Run gpmc.msc to Configure Group Policy Audit Settings
Edit domain’s Default Domain Policy in the Group Policy Management Editor.
Expand Computer Configuration>Windows Settings>Security Settings > Local Policies > Audit Policy and double-click ‘Audit logon events’.
In the Audit logon event properties, select the Security Policy Setting tab and select Success.
Open command prompt and run the command gpupdate/force to update Group Policy.
To know about the failed logon events, filter the Security Event Log for Event ID 4625.
Double-click on any event to see details of the source from where the failed logon attempts were made.
Conclusion
Regularly auditing failed logon attempts through monitoring your Security event logs is necessary for ensuring security and stability of Active Directory environments. Native tools allow you to view these Security event logs but it is perhaps not the most pro-active or user-friendly method. Many organizations find that it makes more sense to deploy an automated solution, like LepideAuditor Suite – Active Directory that provides in depth reporting and real time alerting.
Active directory keeps a log of the last time a domain user has authenticated to the domain (from server 2000 onwards) , the drawback with 2000 is that this value didn’t replicate so you had to query each domain controller and cobble the results together.
After 2003 this value was replicated (after convergence,) to all domain controllers.
Solution
Update Here’s a much better way of showing who logged on last, on a computer-by-computer basis.
There are various scripts that will do this for you, but the best way of finding your users last logon time is to run ADTidy.
Run this on a domain controller and it will list your domain users, the last time they logged on, (and what DC authenticated them).
Note: If you have mobile devices (e.g. phones picking up Exchange mail) these events will be logged as well, so don’t panic if you see authentication events at odd times.
In addition this software will also let you disable/delete inactive accounts, and export the details to CSV file.
Related Articles, References, Credits, or External Links
In part one we built and configured the WDS Server. Now you need to prepare the reference Windows 8 machine so that you can ‘capture’ its image.
Solution
Before you start, make sure that the machine you are imaging has PLENTY of room on one of its local drive(s), because it copies the image locally, before it sends it to WDS.
Place Your Reference Windows 8 Machine in Audit Mode
To put all the software on your reference machine and configure it how you like, the machine needs to be in ‘Audit Mode’ before you start. There are TWO ways to put the machine into audit mode.
Note: While a machine is in audit mode, it will log on automatically as the Administrator, and every time the machine boots sysprep will launch (in anticipation of you needing it).
Option 1: A Newly Built Machine
1. When you have first built the Windows 8 machine, you will see the screen below, Press CTRL+SHIFT+F3, the machine will automatically reboot and enter audit mode.
Option 2: You Are Already in Windows
2. You can also put a Windows 8 machine into audit mode by running the sysprep executable with the /audit switch.
3. Once in Audit mode, install all the program and configure all the settings you want in your master image. When you are happy run the sysprep program, (Or simply reboot, as sysprep launches at every boot when you are in audit mode).
4. Tick the ‘Generalize’ option, select either shutdown or reboot, (If you choose reboot make sure the machine is ready to pXe boot from the network, and the boot order has the NICBEFORE the hard drive, or sysprep will start and rebuild the machine before it’s imaged).
5. Sysprep will run, and shutdown or reboot as requested.
6. When the machine boots press F12 to boot from the WDS server.
7. Note: Now you can see why (in part one) we called the boot image ‘Capture an Image’ and the capture ‘Capture an Image’. Select the capture option.
8. WindowsPE will run at the welcome screen > Next,
Note: If the process fails at this point, usually it’s because the network card driver for this machine IS NOT in the boot image.
9. Select the volume that you want to image, (Note: It will NOT be C: that’s reserved, usually it’s D:) > Give the image a name, this is the name you will see in the WDS console, and when you are imaging the target machines > Enter a comment/description > Next.
10. Browse.
11. Navigate to a local drive, and give the image a name with a .wim extension > Save.
12. Tick the box to upload the image > Supply IP/Name of the WDS server > Connect.
13. Supply credentials to log onto the WDS server > OK.
14. Once authenticated you can select the image group we setup in part one > Next.
15. The image will be created on the reference machine.
