I have been told that enabling auditing on a domain controller imposes too much extra load on a system to enable it in production. I don't know anything about Windows server administration so I cannot easily set up a server myself and do load tests to compare the CPU, memory and disk usage between a system with auditing enabled to a system without it enabled, but I would like to know if this is true, that it imposes an unreasonable amount of extra load for a production server. So is there somewhere that mentions how much load it might add, or does anyone have know-how on how much extra (%) load it would add on a busy server?
Also, is it not just good practice to log the source of failed login attempts? Is there a security standard somewhere that recommends this to be enabled?
Sorry, that makes three questions.
Microsoft, creators of AD DS, for one.
Their AD DS operations guide has an entire category for securing it, and logins are a key thing to look for in signs of compromise. Success and failure.
Also per Microsoft, a baseline recommendations audit setup is quite a bit more sophisticated than just logon. No need to audit every object, but some things are interesting.
For example, likely audit process tracking on a a directory controller is a good idea, since no one is authorized to run extra programs on such security critical hosts.
A test environment is required to do functional testing. Building from scratch, configuring, backup restore testing. Get help setting your own AD DS playground up.
Unlikely that a test environment will be subject to similar loads and performance as production. Instead what you can find out, what is useful auditing information, and what is noise. And how to break things.
In production, do capacity planning and load balance across several hosts. When sized for fast response time and future growth, auditing select high-value events is unlikely to be a huge burden. This is not a very large database, after all.