|
KB2001.815
Problem: Membership Monitor reports do not include who made an account change, even though you have the Look Up
Responsible Person checkbox checked on the control panel applet
This article applies to Membership Monitor.
Last Updated: 12 June 2015
Problem
Membership Monitor reports do not include who made an account change, even though you have the Look Up
Responsible Person checkbox checked on the control panel applet.
Details
Windows does not store information about who made changes to user accounts in the user
account database (SAM or Active Directory). You can, however, enable auditing for these kinds
of changes. When you do, Windows will create an entry in the Event Viewer Security Log at the
time a user account is changed. By examining this log and decoding the SID information and
Event ID numbers, it is possible to reconstruct most user account actions and thus determine
"whodunnit" for any given change.
Background
Auditing must be enabled before any lookups can take place. If auditing is not enabled when a
change happens, then there will be no record of the change. (i.e., you cannot enable auditing
today and hope to find out who did something yesterday.)
- Stand-alone Machines and Member Servers
On stand-alone workstations, servers, or member servers, you must enable auditing on that machine
(as opposed to enabling auditing on the domain, if a domain is present).
Changes to that machine's user database will show up in the Security Log on that machine. In
order for Membership Monitor to determine the responsible person, it must be able to read the Security Log
on that machine.
- NT4 Domain Accounts
Changes to NT4 domain accounts always happen at the PDC, so this is where the Security Log
information is recorded. Changes are propagated out to each BDC, but the BDCs do not generate
auditing entries in their own Security Logs. Membership Monitor therefore needs to be able to
read the Security Log on the NT4 PDC in order to determine the responsible person.
- Single-Master Windows Domain Accounts
If your Windows domain has only a single master, or if you do not have Active Directory
enabled, then all audit information will be on the PDC emulator (FSMO). Membership Monitor
will automatically detect this situation and treat the Single-Master Windows domain as if
it were a regular NT4 domain.
- Multi-Master Windows Domain Accounts
When Active Directory is enabled, either in mixed mode or pure mode, then you may have more than
one writable Domain Controller. In this case, the auditing information is recorded on whatever
DC actually processes the original change. There is no way to determine, without examining the
Security Log on every DC, where the change took place. When Membership Monitor is installed on
a DC with Active Directory enabled, it will automatically examine the Security Logs of all DCs
it can find when trying to look up the responsible person. If you install Membership Monitor on
a non-DC machine but are monitoring the domain, Membership Monitor may not know to examine all
of the Security Logs.
If the relevant Security Log is not available at the time Membership Monitor tries to look up the
responsible person (perhaps because the DC that audited the change is offline), or if the desired information
isn't present (perhaps because auditing isn't enabled), then the information will be omitted from the report.
In order to prevent needless network traffic, Membership Monitor first checks to see that user and group
management auditing is enabled. If not, Membership Monitor will not bother reading through (possibly dozens of)
Security Logs, looking for information that won't be present. Membership Monitor also performs this check
when you enable lookups using the control panel applet. If you get a warning message when trying to enable
lookups, then you should check your audit settings.
Solutions
Enable Success auditing for User and Group Management in the Security Policy for the
machine or domain being monitored. The process for enabling local security auditing is slightly different
for each operating system version. See these articles from the Microsoft Knowledgebase:
To test that auditing is functioning properly, make some changes and then use Event Viewer to inspect the Security log and look
for events with the Category Account Manager, Source Security, and Type Success Audit.
If you cannot find audit records relating to user and group management, then you have not enabled auditing for
the correct category, or you enabled it in the wrong place (on the domain when you meant to target a particular
machine, on a machine when you meant to target the domain, or a local policy when you meant to specificy a
domain policy). Here is a sample showing something similar to what you should see if auditing is enabled
correctly:
Event Viewer Security Log
Detail Record from Security Log
The user account used for running the Membership Monitor service must have sufficient rights to read the
event logs on all machines being monitored. To test this, log in with the service account and use the Event Viewer to
connect to the remote machines and verify that you are able to read both the local and remote event logs (particularly
on the PDC, or the PDC emulators on Win2000 trees).
You may change the Debugging Enabled Registry Setting for Membership Monitor to True in order
to get more detailed information on what Membership Monitor is trying to do, and what information it finds
in the Event Logs.
Caution:
Modifying Registry entries requires basic familiarity with the Windows Registry and its operations.
Incorrect changes to the Registry can result in unpredictable, perhaps non-repairable, damage, up to and including
a non-bootable system! Have a qualified technician make the changes for you if you are not comfortable with the
process. We cannot be responsible for registry problems.
|
Membership Monitor registry settings are located in:
HKEY_LOCAL_MACHINE
Software
Greyware
Membership Monitor
Parameters
|
|
|
