The local AMS Organization Servers group includes the accounts under which the organization’s InTrust servers run. To allow your organization’s InTrust servers to communicate with the server you are setting up, add its account to this group.
For example, if you have two InTrust servers installed (IT1 and IT2), to allow data communication between IT1 and IT2, you can take the following steps:
Then, each time you add a new InTrust server to the organization and need to allow communication between all servers in the organization, you should do as follows:
|
Caution: If you configured non-dbo accounts to access InTrust databases (as described in the Providing Database Access topic), include the corresponding group in the AMS Organization Servers group on all InTrust servers. |
The local AMS Readers group includes the accounts that are permitted to connect to InTrust servers using InTrust Manager in order to run tasks, view the configuration and so on. Include in this group all personnel who are supposed to work with InTrust Manager.
This group is granted the Log on as a batch job right on the InTrust server where the task or job is executed. When you create a task or a job with a specific account, this account is automatically granted the Log on as a batch job right and included in the AMS Readers group.
Members of this group automatically have read access to all objects available in InTrust Manager. This lets the group's members run existing jobs and tasks but not delete or change them. To let an account perform configuration, make the account an InTrust organization administrator, as described in InTrust Organization Administrators.
InTrust offers a number of predefined sites for Microsoft Windows Network and UNIX network; you can use them by selecting the Configuration | Sites node in InTrust Manager.
|
Note: It is recommended that you do not change predefined sites directly to conform to your environment. Instead, consider copying existing predefined sites that correspond to the sites you need, and making changes to the copies. |
You can populate a site with the following objects:
You can use filters to populate InTrust sites basing on:
For example, you want to create an InTrust site with all domain controllers of the domain. For that on the Site Objects step of the New Site Wizard you should click Add button and select All Domain Controllers in | Domain.
InTrust automatically discovers and enumerates site resources in case shortcuts to domains, Active Directory organizational units, Active Directory sites, or IP ranges are used. This means, if you add a new domain controller to a domain processed by InTrust, it will be automatically discovered and included in the corresponding site.
You can perform domain enumeration for the site either by using the Computer Browser service, or by getting the computer list from a domain controller.
|
Caution: In some cases, when an InTrust site is configured to include computers by matching a filter, ‘excessive’ computers may appear in the site after enumeration. This happens if the filter matching cannot be done for some computers in the scope of the site (domain, OU, IP range, etc.) due to specific reasons (for example, if a computer cannot be accessed at the enumeration time). However, to reduce a probability of data loss, such computers are included in the site as if they matched the filter defined for the site objects. InTrust tries to process such computers. If filter matching fails, users are notified by a message. |
InTrust uses the terms operator and recipient interchangeably. They define who or what is the addressee of notifications from InTrust jobs and real-time monitoring rules. Recipients can be grouped into notification groups for notifying multiple recipients at once.
To create a new recipient
Recipients are not necessarily fixed accounts. InTrust provides a way to make a single recipient represent appropriate accounts for multiple situations. These dynamic operators are designed for real-time monitoring purposes, and the account selected for notification depends on the event that triggers the real-time alert.
For example, if your rule uses "Dynamic Operator: Manager of Account in Who Field" as the notification recipient, then InTrust will analyze the contents of the Who field in the alert-triggering event, query Active Directory to find out the initiator's manager and send a message to this manager's address. There are several predefined recipients like this; their names start with "Dynamic Operator".
The dynamic recipient selection is script-based. The scripts that implement it are located under the Configuration | Advanced | Scripts node in InTrust Manager. The names of the predefined scripts for this purpose start with "Address Discovery". You can create your own scripts of this kind by making copies of the predefined scripts and modifying the copies to suit your needs.
To create a new dynamic operator
|
NOTE: Dynamic operators are best used together with rules of the "Single event" type. Using them with rules of other types (such as "Events threshold" or "Missing event") may result in irrelevant notifications or may not make sense. |
Event Log Recipient is a non-messaging type of notification recipient that uses the InTrust event log as the notification destination. If this recipient is specified for a real-time monitoring rule, then every time the rule is matched, InTrust generates an event about the rule match instead of sending a message to someone. The intended use for this feature is to integrate real-time monitoring and forwarding to SIEM systems, which customarily work with log data. This method provides a SIEM-compliant alternative to InTrust alerts.
There is only one event log recipient; you cannot delete it or create new ones.
Event Log Recipient puts all rule match events in the InTrust log. The destination log is located on the InTrust server that processes the site containing the computer where the rule match occurs. Therefore, to avoid losing any of these events, you should get them from all InTrust servers in the organization.
The events always have event ID 17408. For details about the event, see Events from InTrust Notification Engine.
If you start using the InTrust log for rule match events, you turn it from an InTrust-specific resource into a significant security asset. Make sure you treat the log accordingly. For example, think twice before you clear the log and consider tracking user access to it.
If you rely heavily on logging rule match events in your workflow, then it can be tedious to specify Event Log Recipient for individual rules. Consider using the NotifyThroughEventLog.exe utility, which enables Event Log Recipient for all existing rules. You can download the utility from the link provided in Quest Support Knowledge Base article 312739.
This feature relies on the InTrust notification framework, so for logging of the rule match event to work, the following two settings need to be configured:
Enabling just one or the other is not enough for the logging to begin. For details about real-time monitoring policies, see Understanding Real-Time Monitoring Policies.
|
IMPORTANT: Use the Event Log notification type only in real-time monitoring rules. Specifying it in notification jobs is pointless, because it has no effect there. |
If you use InTrust as your SIEM forwarding tool, see Example: Emulating InTrust Real-Time Alerts in SIEM for details.
If you use SIEM agents, refer to the documentation of your tool for information about integrating events with a specific event ID.
© ALL RIGHTS RESERVED. 이용 약관 개인정보 보호정책 Cookie Preference Center