Skip Headers
Oracle® Enterprise Manager Configuration Change Console User's Guide
10g Version 10.2.0.5 for Windows or UNIX

E15313-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

C Component Internal Rule Set Capability Details

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.

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.

Oracle 8i/9i/10g (Audit)

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.

Rule Set Configuration

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.


Rules

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:

  • Select

  • Create

  • Delete

  • Update


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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. If using Schema.Objname pattern, wildcards are not supported in the schema name. Use only one wildcard (*) in Objname if needed.

  5. 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.

  6. 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.

Oracle 8i (Snapshot) and Oracle 9i/10g (Snapshot)

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)

For Oracle 9i/10g (Snapshot)

Rule Set Configuration

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:

  • None

  • Day - once a day at 00:00

  • Hour - once an hour at 00 minutes

  • Month - once a month on the 1st at 00:00

  • Week - once a week on the first day at 00:00


Rules

There are two types of rules you can add to the Database snapshot rule sets.

  1. 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.

  2. 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:

    1. If no rules are defined, no events will be captured.

    2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

    3. 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.

    4. 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.

Microsoft SQL Server 2000 (Audit)

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.

Rule Set Configuration

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.


Rules

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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. 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.

Microsoft SQL Server 2000 (SQL Trace)

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.

Rule Set Configuration

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.


Rules

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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. 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.

Microsoft SQL Server (Snapshot)

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:

Rule Set Configuration

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:

  • None

  • Day - once a day at 00:00

  • Hour - once an hour at 00 minutes

  • Month - once a month on the 1st at 00:00

  • Week - once a week on the first day at 00:00


Rules

There are two types of rules you can add to the Database snapshot rule sets.

  1. 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.

  2. 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:

    1. If no rules are defined, no events will be captured.

    2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

    3. 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.

    4. 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.

Microsoft Active Directory (Trace)

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:

Rule Set Configuration

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.

Rules

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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. 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.

Microsoft Active Directory/LDAP (Snapshot)

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:

Rule Set Configuration

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


Rules

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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. 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.

Microsoft Windows Registry

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.

Rule Set Configuration

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.

Rules

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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. 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.

SNMP Traps

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.

Rule Set Configuration

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.

Rules

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:

  1. If no rules are defined, no events will be captured.

  2. If rules are defined for only some pattern types, only those patterns types will be evaluated.

  3. 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.

  4. 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.