Account Management Events Test

The addition of new users/computers/groups to an Active Directory domain, changes to existing user/computer/group accounts, and deletion of accounts are important to verify that they were performed only by authorized personnel and with no malicious intent. To track such operations, “Audit account management events” provides specific event IDs. Using the Account Management Events test, you can continuously track events with the event IDs grouped under Audit account management events, and be proactively alerted to the sudden addition/modificiation/deletion of users/groups/computers in the Active Directory. You can also use the detailed diagnosis of the test to know which user performed the addition/modification/deletion and when.

Target of the test : An Active Directory server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the server being monitored

Configurable parameters for the test
Parameters	Description
Test Period	This indicates how often should the test be executed.
Host	The host for which the test is to be configured.
Port	Refers to the port used by the EventLog Service. Here it is null.
SuccesseventsinDD	By default, this parameter displays none, indicating that by default none of the successful log audits will be reflected in the detailed diagnosis. If you set this parameter to, say 10, then the test will display only the 10 most recent successful log audits in the detailed diagnosis page. Setting this parameter to all, on the other hand will make sure that all successful log audits are listed in the detailed diagnosis.
FailureeventsinDD	By default, this parameter displays all, indicating that by default all the failed log audits will be reflected in the detailed diagnosis. If you set this parameter to, say 10, then the test will display only the 10 most recent log audits that failed, in the detailed diagnosis page. Setting this parameter to none, on the other hand will make sure that none of the failed log audits are listed in the detailed diagnosis.
Policy Based Filter	Using this page, administrators can configure the event sources, event IDs, and event descriptions to be monitored by this test. In order to enable administrators to easily and accurately provide this specification, this page provides the following options: Manually specify the event sources, IDs, and descriptions in the Filter text area, or, Select a specification from the predefined filter policies listed in the Filter box For explicit, manual specification of the filter conditions, select the No option against the Policy Based Filter field. This is the default selection. To choose from the list of pre-configured filter policies, or to create a new filter policy and then associate the same with the test, select the Yes option against this field.
Filter	If the Policy Based Filter flag is set to No, then a Filter text area will appear, wherein you will have to specify the event sources, event IDs, and event descriptions to be monitored. This specification should be of the following format: {Displayname}:{event_sources_to_be_included}:{event_sources_to_be_excluded}:{event_IDs_to_be_included}:{event_IDs_to_be_excluded}:{event_descriptions_to_be_included}:{event_descriptions_to_be_excluded}. For example, assume that the Filter text area takes the value, OS_events:all:Browse,Print:all:none:all:none. Here: OS_events is the display name that will appear as a descriptor of the test in the monitor UI; all indicates that all the event sources need to be considered while monitoring. To monitor specific event sources, provide the source names as a comma-separated list. To ensure that none of the event sources are monitored, specify none. Next, to ensure that specific event sources are excluded from monitoring, provide a comma-separated list of source names. Accordingly, in our example, Browse and Print have been excluded from monitoring. Alternatively, you can use all to indicate that all the event sources have to be excluded from monitoring, or none to denote that none of the event sources need be excluded. In the same manner, you can provide a comma-separated list of event IDs that require monitoring. The all in our example represents that all the event IDs need to be considered while monitoring. Similarly, the none (following all in our example) is indicative of the fact that none of the event IDs need to be excluded from monitoring. On the other hand, if you want to instruct the eG Enterprise system to ignore a few event IDs during monitoring, then provide the IDs as a comma-separated list. Likewise, specifying all makes sure that all the event IDs are excluded from monitoring. The all which follows implies that all events, regardless of description, need to be included for monitoring. To exclude all events, use none. On the other hand, if you provide a comma-separated list of event descriptions, then the events with the specified descriptions will alone be monitored. Event descriptions can be of any of the following forms - desc, or desc, or desc,or desc, or desc1desc2, etc. desc here refers to any string that forms part of the description. A leading '' signifies any number of leading characters, while a trailing '' signifies any number of trailing characters. In the same way, you can also provide a comma-separated list of event descriptions to be excluded from monitoring. Here again, the specification can be of any of the following forms: desc, or desc, or desc,or desc, or desc1desc2, etc. desc here refers to any string that forms part of the description. A leading '' signifies any number of leading characters, while a trailing '' signifies any number of trailing characters. In our example however, none is specified, indicating that no event descriptions are to be excluded from monitoring. If you use all instead, it would mean that all event descriptions are to be excluded from monitoring. Note: The event sources and event IDs specified here should be exactly the same as that which appears in the Event Viewer window. On the other hand, if the Policy Based Filter flag is set to Yes, then a Filter list box will appear, displaying the filter policies that pre-exist in the eG Enterprise system. A filter policy typically comprises of a specific set of event sources, event IDs, and event descriptions to be monitored. This specification is built into the policy in the following format: {Policyname}:{event_sources_to_be_included}:{event_sources_to_be_excluded}:{event_IDs_to_be_included}:{event_IDs_to_be_excluded}:{event_descriptions_to_be_included}:{event_descriptions_to_be_excluded} To monitor a specific combination of event sources, event IDs, and event descriptions, you can choose the corresponding filter policy from the Filter list box. Multiple filter policies can be so selected. Alternatively, you can modify any of the existing policies to suit your needs, or create a new filter policy. To facilitate this, a Click here link appears just above the test configuration section, once the Yes option is chosen against the Policy Based Filter. Clicking on the Click here link leads you to a page where you can modify the existing policies or create a new one. The changed policy or the new policy can then be associated with the test by selecting the policy name from the Filter list box in this page.
Events During Restart	By default, this flag is set to Yes. This ensures that whenever the agent is stopped and later started, the events that might have occurred during the period of non-availability of the agent are included in the number of events reported by the agent. Setting the flag to No ensures that the agent, when restarted, ignores the events that occurred during the time it was not available.
Stateless Alerts	Typically, the eG manager generates email alerts only when the state of a specific measurement changes. A state change typically occurs only when the threshold of a measure is violated a configured number of times within a specified time window. While this ensured that the eG manager raised alarms only when the problem was severe enough, in some cases, it may cause one/more problems to go unnoticed, just because they did not result in a state change. For example, take the case of the EventLog test. When this test captures an error event for the very first time, the eG manager will send out a critical email alert with the details of the error event to configured recipients. Now, the next time the test runs, if a different error event is captured, the eG manager will keep the state of the measure as critical, but will not send out the details of this error event to the user; thus, the second issue will remain hidden from the user. To make sure that administrators do not miss/overlook critical issues, the eG Enterprise monitoring solution provides the stateless alerting capability. To enable this capability for this test, set the stateless alerts flag to Yes. This will ensure that email alerts are generated for this test, regardless of whether or not the state of the measures reported by this test changes.
UseWMI	The eG agent can either use WMI to extract event log statistics or directly parse the event logs using event log APIs. If this flag is Yes, then WMI is used. If not, the event log APIs are used. This option is provided because on some Windows 2000 systems (especially ones with service pack 3 or lower), the use of WMI access to event logs can cause the CPU usage of the WinMgmt process to shoot up. On such systems, set this parameter value to No.
DD Frequency	Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
User password reset by administrator	Indicates the number of times the user password was changed by the administrator since the last measurement period.	Number	Typically, such an event occurs when the administrator attempts to change some other user’s password in response to a ‘forgot password’ call. You can use the detailed diagnosis of this measure to know which admin user attempted the password change on which computer.
User password reset by users	Indicates the number of times the user password was changed by the users themselves since the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user attempted the password change on which computer.
User accounts created	Indicates the number of user accounts that have been created since the last measurement period.	Number	New user accounts are important to audit to verify that they correspond to a legitimate employee, contractor or application. Outside intruders often create new user accounts to facilitate continued access to the penetrated system. Therefore, you need to eye any sudden increase in the value of this measure with suspicion. You can use the detailed diagnosis of this measure to know which user created new users on which computer.
User accounts deleted	Indicates the number of user accounts that have been deleted since the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user deleted user accounts on which computer.
User account changed	Indicates the number of times the user account has been changed since the last measurement period.	Number	Certain changes to user accounts are important to audit since they can be a tip-off to compromised accounts. For instance, both insider and outsider computer criminals often gain access to a system by socially engineering the help desk to a user’s password. Or a previously disabled account being re-enabled may be suspicious depending on the history and type of the account. You can use the detailed diagnosis of this measure to know which user made changes to user accounts on which computer.
Computer accounts created	Indicates the number of times computer accounts have been created since the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user created computer accounts on which computer.
Computer accounts deleted	Indicates the number of computer accounts that have been deleted since the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user deleted computer accounts on which computer.
Computer accounts changed	Indicates the number of times the computer accounts that have been changed since the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user changed computer accounts on which computer.
User/Computer object disabled	Indicates the number of times the user/computer object was disabled during the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user disabled user/computer objects on which computer.
User/Computer object enabled	Indicates the number of times the user/computer object was enabled during the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user enabled user/computer objects on which computer.
User added to security group	Indicates the number of users who were added to the security group during the last measurement period.	Number	Group changes, especially changes to the group’s membership, are very useful to track since groups are used to control access to resources, link security policies and control wireless and remote access all over a Windows network. Security groups are the only group type that you can assign permissions and rights. Security groups are referred to as “security enabled” groups in the security log. You can use the detailed diagnosis of this measure to know which user added users to the security group on which computer.
Security groups deleted	Indicates the number of security groups that were deleted during the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user deleted security groups on which computer.
Security groups created	Indicates the number of security groups that were created during the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user created security groups on which computer.
Security groups changed	Indicates the number of security groups that were changed during the last measurement period.	Number	You can use the detailed diagnosis of this measure to know which user changed security groups on which computer.

Once the stateless alerting capability is enabled for a test (as discussed above), you will find that everytime the test reports a problem, the eG manager does the following:

Closes the alarm that pre-exists for that problem;
Sends out a normal alert indicating the closure of the old problem;
Opens a new alarm and assigns a new alarm ID to it;
Sends out a fresh email alert to the configured users, intimating them of the new issue.

In a redundant manager setup, the secondary manager automatically downloads the updated eg_specs.ini file from the primary manager, and determines whether the stateless alerting capability has been enabled for any of the tests reporting metrics to it. If so, everytime a threshold violation is detected by such a test, the secondary manager will perform the tasks discussed above for the problem reported by that test. Similarly, the primary manager will check whether the stateless alert flag has been switched on for any of the tests reporting to it, and if so, will automatically perform the above-mentioned tasks whenever those tests report a deviation from the norm.

Note:

The stateless alerting capability is currently available for the following tests alone, by default:

EventLog test
ApplicationEventLog test
SystemEventLog test
ApplicationEvents test
SystemEvents test
SecurityLog test
Account Management Events test

If need be, you can enable the stateless alerting capability for other tests. To achieve this, follow the steps given below:

Login to the eG manager host.
Edit the eg_specs.ini file in the <EG_INSTALL_DIR>\manager\config directory.
Locate the test for which the Stateless Alarms flag has to be enabled.
Insert the entry, -statelessAlerts yes, into the test specification as depicted below:

EventLogTest::$hostName:$portNo=$hostName, -auto, -host $hostName -port $portNo -eventhost $hostIp -eventsrc all -excludedSrc none -useWmi yes -statelessAlerts yes -ddFreq 1:1 -rptName $hostName, 300

Finally, save the file.
If need be, you can change the status of the statelessAlerts flag by reconfiguring the test in the eG administrative interface.

Note:

Since alerts will be closed after every measurement period, alarm escalation will no longer be relevant for tests that have statelessAlerts set to yes.
For tests with statelessAlerts set to yes, statelessAlerts will apply for all measurements of that test (i.e., it will not be possible to only have one of the measurements with stateless alerts and others without).
If statelessAlerts is set to yes for a test, an alarm will be opened during one measurement period (if a threshold violation happens) and will be closed prior to the next measurement period. This way, if a threshold violation happens in successive measurement periods, there will be one alarm per measurement period. This will reflect in all the corresponding places in the eG Enterprise system. For example, multiple alerts in successive measurement periods will result in multiple trouble tickets being opened (one for each measurement period). Likewise, the alarm history will also show alarms being opened during a measurement period and closed during the next measurement period.