Sites are collections of objects used as a target for InTrust operations (Gathering and Real-Time Monitoring). There are 2 types of sites:
Site objects are resolved to computer names or IP Addresses. The sites are accessed through the MSNNSiteProvider (Windows sites) and SolarisSiteProvider (Unix sites) components
For Microsoft Windows Network sites, you can do the following:
A list of objects you can include in a site of the certain type is provided below.
|Objects||Microsoft Windows Site||Unix Site|
|IP address range||Yes||Yes|
|Active Directory site||Yes||No|
|All DCs in the domain||Yes||No|
|All DCs in AD site||Yes||No|
Site enumeration can be initiated in the following ways:
This process is executed using 2 threads running in parallel: one thread resolves computer names/IP addresses, and the other collects information from the resolved objects.
The enumeration process continues without waiting for the whole result set to be returned, so enumeration results are processed as soon as they are available, in the order they are returned.
This process uses various internal lists when determining the actual site membership (the individual computers and IP addresses). There is not one definitive list—real-time monitoring and each gathering job maintain their own lists.
Enumeration process determines the actual site membership in the following way:
|Whole Network||First the domain list is obtained using the method selected for enumeration (Computer Browser or Active Directory). Active Directory domains are enumerated by the DsEnumerateDomainTrusts API function; the return value is a list of domains that trust the current domain. Next, each domain is enumerated individually.|
|Domains||Enumerated according to the domain enumeration method.
Enumeration through Active Directory uses the following LDAP query:
Important: Accounts are not filtered by age.
No enumeration required.
|IP address range||
Only expanded to individual IP addresses.
|Computer list||Computer names/IP addresses are read from the file.|
Enumerated using the following LDAP query:
The OU is the root of the search.
|Active Directory Site||
|All domain controllers in domain||
Enumerated according to the domain enumeration method.
If enumeration through Active Directory is used, first all computers in the domain are discovered using the following LDAP query:
Next, computers with an empty Server-Reference-BL attribute are filtered out. Domain controllers are discovered among the remaining computers.
|All domain controllers in Active Directory site||Always enumerated through Active Directory. The list of domain controllers in obtained from the configuration namespace by running the following LDAP query against the site:|
The final site membership list will contain the original object name (the name used when the object was added to the site) and the name that InTrust can use to connect to the client with. Gathering and real-time monitoring currently respond differently to the site filter check:
If a site is being enumerated for real-time monitoring, the Quest InTrust Real-Time Monitoring service does the following:
If you want to specify your own algorithm for the enumeration of objects in the site, you can use the Enumeration Script option, which prompts you for a script that will perform the enumeration. This option is available:
Selecting Enumeration Script prompts you for the script you want to use. The scripts are located in the Quest InTrust Manager | Configuration | Advanced | Scripts container node.
InTrust comes with the example “Enumeration script: LDAP query” script for this purpose. For your sites, you can use this script, copies of it, or your own scripts.
The “Enumeration script: LDAP query” script has the following parameters, which you can customize without modifying the script itself:
Name of the attribute that will be used as the object name in the list of site objects.
ADSI bind string; for example, “GC:” means that the entire AD forest will be searched, “LDAP:” specifies the current domain.
|Filter||LDAP filter, such as "(objectCategory=serviceConnectionPoint)"|
|Need Deep Search||
What to do if the search in the entire forest finds objects whose names (specified by the Attribute Name parameter) cannot be read:
This parameter is considered only if the Bind String begins with “GC:”.
Search scope in LDAP terms, with the following values: