[Autogenerated] Now let's go ahead and
look at some of this on our test system.
We're gonna go ahead and look at legacy
policy legacy audit policy and compare it
to advance to audit policy and the
categories that are available in each. And
then we'll look at setting that security
options policy to disable legacy audit
policy with G. P. So I'm in my good friend
group Policy Management Council now, and
I'm gonna go ahead and edit the default
domain controllers policy so you can see
some of these audit events. So I'm gonna
go ahead into computer configuration and
just keep in mind that auditing is set in
all cases on a per computer basis. So you
have the ability to in group policy
anyway, said it through computer
configuration security settings and then
for the legacy audit policy. You would go
in under local policies, audit policy, and
this is where you'll see the different
audit categories being set. If you go down
the list to the very bottom, you'll see
advanced audit policy. And if I go ahead
and expand this, you'll see each of the
sub categories of audit policy available.
So under account, log on. I have some
Kerberos related ones under account
management, distribution groups, security
groups account management of different
kinds. Detailed tracking directory service
is access, and this is where you would
actually enable active directory. Auditing
through the directory service is changes
policy, so I can configure this and set it
for success. Auditing again you can. You
can set a different audit, subcategory for
either success or failure or both. What
that means is when an audit event, our
category is configured for success. That
means that whenever a request in that
category is successful, it will log an
event. If you configure failure, that
means whenever this category of event
fails or shows a failure, it will log that
failure. It's important to keep in mind
that for some categories, for example,
like account log on, that can be a very
chatty category. If I go into log on and
log off, access an audit log on if I'm
auditing for failures of log on events.
While it may be important from a security
perspective, you also have to expect
you're gonna get a lot of false positives
where users just fat fingered their
passwords and ended up locking out their
account or failing to log on. You're gonna
get a lot of those kind of failed log on
type events. So you have to think about
when you're configuring logging, not
automatically turning on both success and
failure, but really letting your needs
around security auditing drive the
configuration. That's most useful now. I
talked a little bit about that policy that
allows you to kind of squelch or silence
legacy audit policy. And that's right
here. Audit force audit policy,
subcategory settings to override audit
policy, subcategory settings. So if I go
ahead and enable this, that will
essentially silence those events that show
up within the event log related to the legacy audit policy events.