Descriptions of the various Component Internal rule sets are already included earlier in the document, but this appendix is meant to capture the details that might not be covered earlier.As discussed earlier in this book, there are two types of monitoring capabilities, or rule sets, in the Configuration Change Console. The first is the monitoring done at the operating system level, such as Files (changes, reads), Processes (starts and stops), and operating system Users (login and logouts). The second type is referred to as Component Internal Rule Sets. These are monitoring capabilities for entities inside of an application or piece of software.The following lists the component internal rule set capabilities that this release of Configuration Change Console supports with a description of capabilities.
Oracle 8i/9i/10g (Audit) - Monitor any database entity or user for change or select activity. Uses the Oracle audit capability of the database for near real-time monitoring.
Oracle 8i (Snapshot) - Monitor schema changes or change to the output of a SQL query that runs periodically.
Oracle 9i/10g (Snapshot) - Monitor schema changes or change to the output of a SQL query that runs periodically.
Microsoft SQL Server 2000 (Audit) - Monitor any database entity or user for change or select activity. Uses the SQL Server auditing capability of the database for near real-time monitoring.
Microsoft SQL Server 2000 (SQL Trace) - Monitor any pattern in SQL statements for activity. Uses the SQL Server auditing capability of the database for near real-time monitoring.
Microsoft SQL Server (Snapshot) - Monitor schema changes or change to the output of a SQL query that runs periodically.
Microsoft Active Directory (Trace) - Monitor changes to User, Group, or Computer entities in near real-time using the auditing capabilities of Active Directory.
Active Directory/LDAP (Snapshot) - Monitor changes to User, Group, or Computer entities using a polling/snapshot capability. Uses standard LDAP interfaces for access.
Microsoft Windows Registry - Monitor key or value changes using Microsoft APIs for near real-time monitoring.
SNMP Traps - Receive SNMP traps from any system that can send traps like network hardware or another application.
Each component internal monitoring rule set is discussed in detail in the rest of this appendix. For each rule set, the Configuration parameters and rule definition options are discussed in detail.
This monitoring capability uses the Oracle audit subsystem to gather audit trails of changes. The Configuration Change Console filters the audit log and uses its rule set and rule configurations for a component to determine what is important for Configuration Change Console.
The agent will not set the audit subsystem settings. These need to be done manually as part of installing the agent to monitor Oracle in audit mode. See the installation documentation for instructions on how to set up an Oracle database for audit monitoring. The rest of this chapter assumes that the database you are monitoring is already configured for auditing and that you have already set up the audit system to audit the entities you will be monitoring from within Configuration Change Console.
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-1 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
Connection URL |
The connection URL to the database of the format jdbc:oracle:thin:@localhost:1521:oraclesid Under normal operations, the only things to change here are the hostname (shown as localhost above) and the sid of the database (shown as oraclesid above). |
|
User Name |
A database user that has read access to the audit trail data in the Oracle database. This user should not have write access to any production data. |
|
Password |
The password for the audit read-only user. |
|
Ignore Events Prior to Agent Update |
Check this if you want CCC monitoring to start only when the component was created. If the audit log in the database has old records and you do not check this box, then those historic events will also be monitored. |
|
User Login Filter |
Selects whether the agent should capture login/logout events for users defined in the rules in addition to other types of events. |
|
Report Success Event Only |
Select whether you want to capture only events that were successful or also failed attempts as well, as in cases when someone tries to delete a record but the delete failed. |
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-2 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
User |
The database user name that is making a change. A single wildcard can be used anywhere in the pattern. For instance you can include any users starting with the letter A by using pattern "A*". |
|
Host |
The host from which a database connection is connecting. You can use this to monitor activity from a specific host versus another host. A single wildcard can be used anywhere in the pattern. |
|
Terminal |
The terminal on a host from which a database connection is connecting. You can use this to monitor activity from a specific terminal on a host versus another terminal. A single wildcard can be used anywhere in the pattern. |
|
Osuser |
The operating system user that is connecting to the database. A change in a database will be done by a database user, but there was an operating system user that first connected, for example using SQL*PLUS to make the change. A single wildcard can be used anywhere in the pattern. |
|
Objname |
The name of the object to monitor. The object name may or may not include the schema owner depending on your needs. If you do not include the owner, then the same object name in all schemas will trigger an event if they change. A single wildcard can be used anywhere in the entity name (not the schema owner name) part of the pattern. |
|
Event |
The event type to capture, for instance:
|
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under the LDAP Users and Groups section of the Rules screen.
When adding patterns for a pattern type user or OS user, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
For pattern type Objname, both Objname and Schema.Objname formats are supported. For example: The pattern include foo will capture all events on foo in any schema. Include system.foo* will only capture them in the system schema.
If using Schema.Objname pattern, wildcards are not supported in the schema name. Use only one wildcard (*) in Objname if needed.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for "User" pattern type: Include system, Exclude syst*, and actions by "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for "User" pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the SQL queries that runs periodically, each time the output of the queries are compared to look for changes. The difference between these snapshot rule sets and the Audit rule set is that the events are not detected in real time and there are certain pieces of information lost such as the user that made the change, the exact time a change happened. There are some benefits to these rules sets, however, in that you can get the before and after values of an entity or query monitored.
The user that is configured to do schema monitoring using include/exclude rules (as opposed to SQL query rules) must have read access to the following tables to perform the monitoring:
For Oracle 8i (Snapshot)
sys.dba_tables
sys.dba_tab_columns
sys.dba_constraints
sys.dba_views
sys.dba_objects
For Oracle 9i/10g (Snapshot)
sys.dba_tables
sys.dba_tab_columns
sys.dba_constraints
sys.dba_views
sys.dba_objects
sys.dba_procedures
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-3 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
Connection URL |
The connection URL to the database of the format: jdbc:oracle:thin:@localhost:1521:oraclesid Under normal operations, the only things to change here are the hostname (shown as localhost above) and the sid of the database (shown as oraclesid above). |
|
User Name |
A database user that has read access to the sys.* tables that store schema definition as well as any tables you will monitor through SQL queries. Any SQL query that you create as part of a snapshot rule set needs to be executable by the user defined here. This user MUST not have write access to any critical/production data. |
|
Password |
The password for the audit read-only user. |
|
Include Schemas/Databases |
The schemas to include in this monitoring. For instance, if you were only SYS, enter SYS here. |
|
Max Rows Returned |
When you use this rule set to monitor a SQL query that you define and if you set a baseline interval, the output of this query will be brought back to the server, stored and be available to show on the UI. This input lets you limit how many rows to return in each SQL query execution to ensure you do not overwhelm the Configuration Change Console. It is not recommended to return more than 1000 rows. If you need more than this, consider creating multiple SQL queries to break your request up into smaller ones. |
|
Baseline Interval |
The interval that the agent should store a copy of the SQL results it captures. The agent will execute the query automatically every 5 minutes, but will only save a copy of the results based on this interval. The options are:
|
There are two types of rules you can add to the Database snapshot rule sets.
SQL Query - lets you define any ad hoc SQL query that will run periodically by the agent. When the output of the SQL query changes, that will lead to one event being reported by the Configuration Change Console agent.
You can create up to 50 SQL statements to execute for this rule set in a single component. When creating the SQL query, you must ensure that the user configured in the rule set configuration settings above can execute the query. The query should not have a semicolon ";" or other terminating string at the end.
If you want to save a copy of the output from the SQL statement according to the Baseline Interval defined in the Rule Set Configuration screen, click the Record Baseline option. These baselines will be viewable along with the ability to perform a Comparison in the Database Inventory screen.
Include/Exclude - monitors only the schema of the selected schemas/databases (defined in the Rule Set Configuration screen as described above). Here you can include/exclude patterns of schema elements you want to monitor for changes.
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-4 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
Table |
The entered pattern is a table name. Events will be reported at the table level, for example, table added, deleted, or modified (one event per table changed). A single wildcard can be used anywhere in the pattern. |
|
Table.attribute |
The entered pattern is a table.attribute name. Events will be reported at the attribute level when an attribute changes (one event per attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Table.column |
The entered pattern is a table.column name. Events will be reported at the column level when a column is added, deleted, or modified (one event per column changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Table.column.attribute |
The entered pattern is a table.column.attribute name. Events will be reported at the attribute level when an attribute changes (one event per column attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Table.constraint |
The entered pattern is a table.constraint name. Events will be reported at the constraint level (one event per constraint changed). A single wildcard can be used anywhere in the pattern. |
|
Table.constraint.attribute |
The entered pattern is a table.constraint.attribute name. Events will be reported at the attribute level (one event per constraint attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
View |
The entered pattern is a view name. Events will be reported at the view level when a view is created, deleted or modified (one event per view changed). A single wildcard can be used anywhere in the pattern. |
|
View.attribute |
The entered pattern is a view.attribute name. Events will be reported at the attribute level (one event per attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
View column |
The entered pattern is a view.column name. Events will be reported at the column level (one event per column changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
View.column.attribute |
The entered pattern is a view.column.attribute name. Events will be reported at the attribute level (one event per column attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Procedure |
The entered pattern is a procedure name. Events will be reported at the procedure level (one event per procedure changed). A single wildcard can be used anywhere in the pattern. |
|
Procedure.attribute |
The entered pattern is a procedure.attribute name. Events will be reported at the attribute level (one event per attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
All |
The entered pattern applies to all pattern types. Events will be reported at the table level. One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). You can also specify a pattern of only "*" to monitor every schema object for schema change. |
For Oracle 8i, Packages and objects within packages are not monitored in the current version. For Oracle 9 agent modules, procedure objects within packages can be tracked for change activity, assuming they are defined as public rather than private. Procedures with packages are monitored as if they were any other procedure. Packages themselves are not monitored, nor are any of their attributes.
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under the LDAP Users and Groups section of the Rules screen.
When adding patterns for pattern type user or osuser, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for the User pattern type: Include system, Exclude syst*, actions by "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for User pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the SQL Server tracing subsystem to gather audit trails of changes. The difference between this module and the Trace version is that this module uses the objects that were accessed or changed instead of the SQL statements that were executed. The Configuration Change Console filters the log and uses its rule set and rule configurations for a component to determine what is important for Configuration Change Console.
The agent will not configure the trace subsystem settings. These need to be done manually as part of installing the agent. See the Installation Documentation for instructions on prerequisites for monitoring SQL Server 2000 in audit mode. The rest of this chapter assumes that the database you are monitoring is already configured for auditing and that you have already set up the audit system to audit the entities you will be monitoring from within Configuration Change Console.
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-5 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
Connection URL |
The connection URL to the database of the format: jdbc:sqlserver://localhost:1433;databaseName=<server-name> Under normal operations, the only things to change here are the hostname (shown as localhost above) and the name of the database (shown as <server-name> above). |
|
User Name |
A database user that has read access to the audit trail data in the database. This user should not have write access to any production data. |
|
Password |
The password for the audit read-only user. |
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-6 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
User |
The database user name that is making a change. A single wildcard can be used anywhere in the pattern. For instance you can include any users starting with the letter A by using pattern "A*". |
|
Host |
The host from which a database connection is connecting. You can use this to monitor activity from a specific host versus another host. A single wildcard can be used anywhere in the pattern. The pattern for this pattern type is case insensitive. |
|
Appname |
The application name used to connect to the database to make the change or access. A single wildcard can be used anywhere in the pattern. The pattern for this pattern type is case sensitive. |
|
Objname |
The name of the object to monitor. The object name may or may not include the schema owner depending on your needs. If you do not include the owner, then the same object name in all schemas will trigger an event if they change. A single wildcard can be used anywhere in the entity name (not the schema owner name) part of the pattern. |
|
Dbname |
The name of the database in the SQL Server installation to monitor. |
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under LDAP Users and Groups section of the Rules screen.
When adding patterns for pattern type user or osuser, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for the User pattern type: Include system, Exclude syst*, and actions by "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for User pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the SQL Server tracing subsystem to gather audit trails of changes. The difference between this module and the Audit version is that this module uses the SQL statements that were used instead of monitoring by the objects that had change or access. The Configuration Change Console filters the log and uses its rule set and rule configurations for a component to determine what is important for Configuration Change Console.
The agent will not configure the trace subsystem settings. These need to be done manually as part of installing the agent. See the Installation Documentation for instructions on prerequisites for monitoring SQL Server 2000 in audit mode. The rest of this chapter assumes that the database you are monitoring is already configured for auditing and that you have already set up the audit system to audit the entities you will be monitoring from within Configuration Change Console.
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-7 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
Connection URL |
The connection URL to the database of the format: jdbc:sqlserver://localhost:1433;databaseName=<server-name> Under normal operations, the only things to change here are the hostname (shown as localhost above) and the name of the server (shown as <server-name> above). |
|
User Name |
A database user that has read access to the audit trail data in the database. This user should not have write access to any production data. |
|
Password |
The password for the audit read-only user. |
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-8 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
User |
The database user name that is making a change. A single wildcard can be used anywhere in the pattern. For instance you can include any users starting with the letter A by using pattern "A*". |
|
Host |
The host from which a database connection is connecting. You can use this to monitor activity from a specific host versus another host. A single wildcard can be used anywhere in the pattern. |
|
Appname |
The application name used to connect to the database to make the change or access. A single wildcard can be used anywhere in the pattern. |
|
sqltext |
The name of the object to monitor. The object name may or may not include the schema owner depending on your needs. If you do not include the owner, then the same object name in all schemas will trigger an event if they change. A single wildcard can be used anywhere in the entity name (not the schema owner name) part of the pattern. |
|
Dbname |
A pattern of SQL text to match. No wildcard is supported in this input, but the text is considered to be a fragment of a larger SQL statement automatically. You can search for any part of the statement, such as the table name or where clause, for example. |
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under LDAP Users and Groups section of the Rules screen.
When adding patterns for pattern type user or osuser, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for "User" pattern type: Include system, Exclude syst*, and actions by the "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for "User" pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the SQL queries that run periodically, each time the output of the queries are compared to look for changes. The difference between these snapshot rule sets and the Audit rule set is that the events are not detected in real time and there are certain pieces of information lost such as the user that made the change and the exact time a change happened. There are some benefits to these rules sets, however, in that you can get the before and after values of an entity or query monitored.
The user that is configured to do schema monitoring using include/exclude rules (as opposed to SQL query rules) must have read access to the following tables to perform the monitoring:
<database_name>.dbo.sysuserssystables
<database_name>.dbo.sysobjectssysprocedures
<database_name>.dbo.syscolumnssyscolumns
<database_name>.dbo.systypessysconstraints
<database_name>.dbo.sysconstraintssyschecks
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-9 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
Connection URL |
The connection URL to the database of the format: jdbc:sqlserver://localhost:1433;databaseName=<server-name> Under normal operations, the only things to change here are the hostname (shown as localhost above) and the name of the server (shown as <server-name> above). |
|
User Name |
A database user that has read access to the dbo.* tables that store schema definition as well as any tables you will monitor through SQL queries. Any SQL query that you create as part of a snapshot rule set needs to be executable by the user defined here. This user MUST not have write access to any critical/production data. |
|
Password |
The password for the audit read-only user. |
|
Include Schemas/Databases |
The schemas to include in this monitoring. |
|
Max Rows Returned |
When you use this rule set to monitor a SQL query that you define and if you set a baseline interval, the output of this query will be brought back to the server, stored and be available to show on the UI. This input lets you limit how many rows to return in each SQL query execution to ensure you do not overwhelm the Configuration Change Console. It is not recommended to return more than 1000 rows. If you need more than this, consider creating multiple SQL queries to break your request up into smaller queries. |
|
Baseline Interval |
The interval in which the agent should store a copy of the SQL results it captures. The agent will execute the query automatically every 5 minutes, but will only save a copy of the results based on this interval. The options are:
|
There are two types of rules you can add to the Database snapshot rule sets.
SQL Query - lets you define any ad hoc SQL query that will run periodically by the agent. When the output of the SQL query changes, that will lead to one event being reported by the Configuration Change Console agent.
You can create up to 50 SQL statements to execute for this rule set in a single component. When creating the SQL query, you must ensure that the user configured in the rule set configuration settings above can execute the query. The query should not have a semicolon ";" or other terminating string at the end.
If you want to save a copy of the output from the SQL statement according to the Baseline Interval defined in the Rule Set Configuration screen, click the Record Baseline option. These baselines will be viewable along with the ability to perform a Comparison in the Database Inventory screen.
Include/Exclude - monitors only the schema of the selected schemas/databases (defined in the Rule Set Configuration screen as described above). Here you can include/exclude patterns of schema elements you want to watch for changes.
You can create up to 50 include or exclude rules for this rule set in a single component The following pattern types are available for creating rules.
Table C-10 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
Table |
The entered pattern is a table name. Events will be reported at the table level, for example, table added, deleted, modified (one event per table changed). A single wildcard can be used anywhere in the pattern. |
|
Table.column |
The entered pattern is a table.column name. Events will be reported at the column level when a column is added, deleted, or modified (one event per column changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Table.column.attribute |
The entered pattern is a table.column.attribute name. Events will be reported at the attribute level when an attribute changes (one event per column attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Table.constraint |
The entered pattern is a table.constraint name. Events will be reported at the constraint level (one event per constraint changed). A single wildcard can be used anywhere in the pattern. |
|
Table.constraint.attribute |
The entered pattern is a table.constraint.attribute name. Events will be reported at the attribute level (one event per constraint attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
View |
The entered pattern is a view name. Events will be reported at the view level when a view is created, deleted or modified (one event per view changed). A single wildcard can be used anywhere in the pattern. |
|
View.attribute |
The entered pattern is a view.attribute name. Events will be reported at the attribute level (one event per attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
View column |
The entered pattern is a view.column name. Events will be reported at the column level (one event per column changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
View.column.attribute |
The entered pattern is a view.column.attribute name. Events will be reported at the attribute level (one event per column attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
Procedure |
The entered pattern is a procedure name. Events will be reported at the procedure level (one event per procedure changed). A single wildcard can be used anywhere in the pattern. |
|
Procedure.attribute |
The entered pattern is a procedure.attribute name. Events will be reported at the attribute level (one event per attribute changed). One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). |
|
All |
The entered pattern applies to all pattern types. Events will be reported at the table level. One wildcard can be used anywhere in each element of the pattern (each element is separated by a period '.'). You can also specify a pattern of only "*" to monitor every schema object for schema change. |
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under the LDAP Users and Groups section of the Rules screen.
When adding patterns for the pattern type user or osuser, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for "User" pattern type: Include system, Exclude syst*, and actions by "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for "User" pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the Active Directory audit APIs to gather audit trails of changes. The difference between this module and the snapshot version is that this module can capture the exact time that a change occurred and can also capture the user that made the change. This rule set must be assigned to an agent that is actually on the device on which the Microsoft Active Directory is installed. The Configuration Change Console filters the log and uses its rule set and rule configurations for a component to determine what is important for Configuration Change Console.
The Active Directory rule set can detect the following types of activities:
Add or delete users
User password changes
Add or remove a user from a group
Assign a user to manage a computer
Add or delete a group
Add or remove a computer into or from the domain
Change a computer attribute
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-11 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
There are no other configuration parameters for this rule set because it is understood that the device being monitored for this rule set is the same device on which the Active Directory is installed. All APIs required will be available locally to the agent.
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-12 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
User |
Monitor changes to users defined in the Active Directory. A single wildcard can be used anywhere in the pattern. |
|
Computer |
Monitor changes to computers defined in the Active Directory. A single wildcard can be used anywhere in the pattern. |
|
Group |
Monitor changes to groups defined in the Active Directory. A single wildcard can be used anywhere in the pattern. |
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under LDAP Users and Groups section of the Rules screen.
When adding patterns for a pattern type user or osuser, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for the "User" pattern type: Include system, Exclude syst*, and actions by the "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for the "User" pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the LDAP APIs to monitor either Active Directory or any other standard compliance LDAP server for changes to Users, Groups, or Computers. The difference between this module and the trace version is that this module uses a polling/snapshot approach where the content is checked periodically and compared to identify changes. Using this rule set, you cannot find the exact time of a change, or the user that made the change. This rule set can exist on an agent that is on a different device than the LDAP server.
The Active Directory rule set can detect the following types of activities:
Add or delete users
User password changes
Add or remove a user from a group
Assign a user to manage a computer
Add or delete a group
Add or remove a computer into or from the domain
Change a computer attribute
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-13 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
LDAP URL |
Connection URL to the LDAP server, of the format where you replace the host name where 127.0.0.1 is located and the port where 389 is located. ldap://127.0.0.1:389 |
|
Username |
The username to connect to in LDAP to monitor the entities. This user needs read only access to the LDAP entities you are monitoring. |
|
Password |
Password for the monitoring user. |
|
Template Base |
LDAP template base from which to start monitoring. The template.base value should be in entered in the format of: DC=<node element> For all node values. If the node name features a period (.) you will need to add an additional DC=<node element> marker, separated by a comma (,) for each string following a period. Note that the period itself is not included. For example, if you wish to specify domain/base node mydomain.com as the template.base value you would enter the following in the template.base field: DC=mydomain,DC=com |
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-14 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
User |
Monitor changes to users defined in Active Directory. A single wildcard can be used anywhere in the pattern. |
|
Computer |
Monitor changes to computers defined in Active Directory. A single wildcard can be used anywhere in the pattern. |
|
Group |
Monitor changes to any of these using a single pattern. A single wildcard can be used anywhere in the pattern. If you want to monitor every object in LDAP, you could have a single rule to include * for all pattern types. |
If you have integrated your Configuration Change Console server with an LDAP server, you can also import groups and users from your LDAP server instead of entering them directly as patterns. If the group structure changes in your LDAP server, it will be automatically updated to the agent to adjust the monitoring needs. You can add LDAP users and groups by clicking on the Add Instance() link under LDAP Users and Groups section of the Rules screen.
When adding patterns for the pattern type user or osuser, you can also populate these patterns by selecting users that have been detected over time by the Configuration Change Console agent. Click on the Select from Detected Users link to select previously discovered users instead of entering the patterns manually.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for the "User" pattern type: Include system, Exclude syst*, and actions by "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for the "User" pattern type: Include *, exclude *, all events will be captured.
This monitoring capability uses the Microsoft Windows Registry audit APIs to gather audit trails of changes. This rule set must assigned to an agent that is actually on the device of the registry you want to monitor.
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-15 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
There are no other configuration parameters for this rule set because it is understood that the device being monitored for this rule set is the same device you are monitoring. All APIs required will be available locally to the agent.
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-16 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
Key |
Monitor changes based only on a key value. You can use only the first n characters in a key name, and all keys matching this pattern will be monitored (similar to file monitoring rules.) You can use one wildcard in the last element (separated by "/") only. |
|
Value |
Monitor changes based only on a value for a key. You can use only the first n characters in a value name, all keys matching this pattern will be monitored (similar to file monitoring rules.) You can use one wildcard in the last element (separated by "/") only. |
|
All |
Check this pattern against both the key and the value. You can use only the first n characters in a key name, and all keys matching this pattern will be monitored (similar to file monitoring rules.) You can use one wildcard in the last element (separated by "/") only. |
If you want to filter the changes against Windows Registry by the user that made them, you can add an OS User rule set to the same component and then check the box on this rule set that indicates that these users are for filtering other types of rule sets. Then in this Windows Registry rule screen, check the box that says Filter change data by Users defined in this component.
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for the "User" pattern type: Include system, Exclude syst*, and actions by "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for the "User" pattern type: Include *, exclude *, all events will be captured.
The Windows Registry monitoring policies are based on additions, modifications and deletions of Registry keys and values.
The Patterns must start with HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, HKEY_CLASSES_ROOT, HKEY_USERS or HKEY_CURRENT_CONFIG.
You may specify exclusion of sub-directories under the inclusion directories. For example, to monitor HKEY_LOCAL_MACHINE\Software, but not HKEY_LOCAL_MACHINE\Software\Oracle:
Include HKEY_LOCAL_MACHINE\Software
Exclude HKEY_LOCAL_MACHINE\Software\Oracle
Any changes under HKEY_LOCAL_MACHINE\Software will be reported. No changes will be reported under HKEY_LOCAL_MACHINE\Software\Oracle or child keys.
This monitoring capability allows the agent to listen for SNMP traps which may be sent from any system. Network hardware can be configured to send SNMP traps when a configuration change occurs. Many software applications can also send traps when there are configuration or critical alerts that need to be monitored. This rule set will configure the agent to listen for traps and is used to define rules to filter which SNMP traps are meaningful for this agent to collect and send back to the server.
When you add this rule set to a component, you must set the options under the Configure link shown for the rule set. The following are the options to be configured:
Table C-17 Options for Rule Sets
| Option | Description |
|---|---|
|
Is Enabled |
Check this box to enable this rule set. |
|
Transport |
The transport mechanism that will be used to listen for traps. The default here is UDP. This should only be changed if you know your system will use another transport mechanism such as TCP. |
|
Port |
The port on which the agent will listen to traps. This needs to match the port that your external system will be connecting to when sending a trap. |
|
OIDs |
A list of OIDS separated by commas that contain the user name that made the change. This is important when reporting who made a change. Example: 1.2.4,5,1.2.3.5 |
There are no other configuration parameters for this rule set because it is understood that the device being monitored for this rule set is the same device you are monitoring. All APIs needed will be available locally to the agent.
You can create up to 50 include or exclude rules for this rule set in a single component. The following pattern types are available for creating rules.
Table C-18 Pattern Types for Rules
| Pattern Type | Description |
|---|---|
|
Community |
The community string (for example: "public") on which to match. This pattern can have one wildcard anywhere in the string. |
|
Enterprise |
The enterprise OID string (for example: "1.3.4.*") on which to match. This pattern can have one wildcard anywhere in the string. |
|
AgentAddress |
IP Addresses to match from where a change occurred. This pattern can have one wildcard anywhere in the string. |
|
SourceAddress |
IP Addresses to match from where a change occurred. This pattern can have one wildcard anywhere in the string. Source and agent address normally would be the same unless some proxy system exists between the person making a change and the system triggering the trap. |
|
GenericType |
A number matching the GenericType from a trap. |
|
SpecificCode |
A number matching the GenericType from a trap. |
|
Binding |
Plain text search on a value of an OID. For instance, to capture only events where OID 1.3.6.1.2.1.2.2.1 contains the text IP Packet, then this pattern would be: 1.3.6.1.2.1.2.2.1=IP Packet |
The following guidelines should be followed when creating rules for this rule set:
If no rules are defined, no events will be captured.
If rules are defined for only some pattern types, only those patterns types will be evaluated.
Patterns without a wildcard (*) take precedence over patterns with a wildcard of the same pattern type. For example: With two rules for the "User" pattern type: Include system, Exclude syst*, and actions by the "system" user will be captured.
Include patterns take precedence over excludes when the pattern lengths are the same for a given pattern type. For example: With two rules for the "User" pattern type: Include *, exclude *, all events will be captured.