Group Policy -> Security Settings -> Local Polices -> Audit Policy
Here is what a good audit policy will discover:
Who is trying to logon.
Which files have been deleted.
Who did it!
‡
Incidentally, unlike other Group Policy settings, Microsoft have not created an 'Explain' tab for these policies, however, if you right click and select 'Help', there
is a comprehensive explanation of each policy setting.
Trap: If you are intending to set Local Policies for your actual Windows Server 2003 Domain
Controller, then you should go to the All Programs, Administrative Tools,
Domain CONTROLLER policy. (Audit policies for Member Servers and XP
clients can be set at the Domain or OU level).
As an MCT trainer, I can thoroughly recommend TrainSignal because they
provide practical hands on training. In particular, I like the way TrainSignal cover all learning methods, instructor lead, video and of course text material. You can either take one module, for example Group Policy or go for
a combination of modules.
See more about Group Policy training here
Watch out for two similar and potentially confusing policies, 'Audit Account Logon events' and 'Audit
Logon events'. The difference is that Audit Logon events (the shorter
one) means
that you are checking who is pressing Ctrl Alt, Del at the domain controller
(or desktop); whereas the Audit Account Logon
events (the longer one) generates an event every
time a user connects to that server across the network.
In terms of strategy, decide whether you simply want to record logon failures -
possible illegal access attempts, or whether you also need to audit success.
Once you enable security policies, check Microsoft's Event Viewer's
Security Log (not system log) for user activity. Another tip: once you become serious about security,
increase the size of the log from 512 K to at least 10 Mb.
If you need to record who is accessing shares, or who is deleting files,
then first you must enable, * 'Audit Object
Access'. Only when you have thrown the Object Access 'master
switch', can you start checking who is doing what to your folders and
printers.
I have lumped together, account management, privilege use and directory service access.
These are three settings that only big companies need to audit. It is all well and
good recording lots of events, but ask yourself, 'Who will have the time to
scour through zillions of events?' Better to record only essential
settings, that way, you will easily spot security breaches.
If you enable process tracking you should get the sack! Stern words to make a serious point.
My point is that Auditing eats up CPU cycles, in fact, process tracking is so intensive that your
server will grind to a halt. Perhaps you can see why I would forbid
process tracking. People
then ask me 'Why would Microsoft include process tracking if it's so crippling?'.
The answer
is so that developers can troubleshoot their new programs.
Here we have the classic Group Policies to track who does what on the servers or local computers. Some audit settings need to be
all the time, while other you need just for troubleshooting. Configuring the Group Policy settings is not difficult, provided you have an action plan based on the appropriate security classification of
your organization.
