Chat now with support
Chat with Support

IT Security Search 11.4.1 - User Guide

Welcome to IT Security Search

Quest IT Security Search provides IT administrators, IT managers and security teams with a way to navigate the expanse of information about the enterprise network. It helps you achieve the following:

  • Examine what is going on
  • Assess the efficiency of security practices
  • Track security incidents
  • Track incidents related to operations
  • Have up-to-date information about users, computers, file server status and more at your fingertips
  • Perform recovery operations if IT Security Search is connected to Recovery Manager for Active Directory

The search engine-like interface helps you pinpoint the data you need using only a few searches and clicks.

Installing IT Security Search

To set up IT Security Search, run the ITSearchSuite.exe installation package. You can customize the installation path and the port that will be used for getting data.

Compatibility

The following versions of data-providing systems are supported in this version of IT Security Search:

  • InTrust 11.4.1, 11.4, 11.3.2, 11.3.1, 11.3
  • Change Auditor 7.0.3, 7.0.2, 7.0.1, 7.0, 6.9.5, 6.9.4, 6.9.3, 6.9.2, 6.9.1, 6.9
  • Enterprise Reporter 3.2.1, 3.2, 3.1, 3.0
  • Recovery Manager for Active Directory 10.0.1, 10.0, 9.0.1, 9.0, 8.8.1
  • Active Roles 7.4.1, 7.4, 7.3.2, 7.3.1, 7.2.1, 7.2, 7.1

Software Requirements

  • Operating system:
    • Microsoft Windows Server 2019
    • Microsoft Windows Server 2016
    • Microsoft Windows Server 2012 R2
    • Microsoft Windows Server 2012
    • Microsoft Windows Server 2008 R2
  • Additional software:
    • Microsoft .NET Framework 4.7.2 or later
    • Microsoft Windows PowerShell 3.0 or later
    • Microsoft SQL Server 2012 or later (all editions)
      This is a requirement of the IT Security Search Warehouse component, which needs it for internal configuration management.
  • Additional requirements for the Recovery Manager for Active Directory connector:
  • Additional requirements for the Active Roles connector:
    • Active Roles Management Tools
    • The PowerShell script execution policy must be set to RemoteSigned.

Browser Compatibility

The IT Security Search Web interface works correctly with the following browsers:

  • Microsoft Edge
  • Microsoft Internet Explorer 11
  • Google Chrome 72.0 or later
  • Mozilla Firefox 65.0 or later

The minimum supported monitor resolution is 1024x768.

Hardware Requirements

  • CPU: 6 cores minimum; 16 cores recommended
  • RAM: 8GB minimum; 16GB or more recommended
  • Disk: 200GB (SSD recommended); disk space requirements are very dependent on the volume of Enterprise Reporter and Active Roles data being processed, because the index size varies proportionally; the indexes for Change Auditor, Recovery Manager for AD and InTrust data do not consume any disk space on the IT Security Search computer, because they are located in the data stores used by these systems
  • If you deploy on a virtual machine, make sure the CPU and memory requirements above are met, and do not overload the virtual machine host

To find out the disk requirements for IT Security Search installation, consider the sections below. They describe how much disk space is used for indexing data provided by specific connectors.

Disk Space for Legacy Enterprise Reporter Data

These numbers are for a sample environment with 10000 of each type of Enterprise Reporter object. Scale the values according to your own circumstances.

Object type Size of an index entry Number of objects Size of the index
Computers 1KB 10000 10MB
Files 0.2KB 10000 2MB
Groups 2.5KB 10000 25MB
Shares 1KB 10000 10MB
Users 2KB 10000 20MB
Total   50000 67MB

Disk Space for Enterprise Reporter Data in Warehouse

These are the average index entry sizes for each type of Enterprise Reporter object. Use them in calculating the required disk space for your particular on-premises or hybrid environment.

Note that there are generally multiple index entries per object, depending on how often objects are changed.

Object type

Average size

of an index entry,

in kilobytes

AD Permissions

2.1

AD Contacts

3.3

Computers

1.6

Groups

1.5

Files

1.5

OUs

2.3

Shares

2.1

Users

1.6

Azure Applications

1.6

Azure Contacts

1.6

Azure Devices

5

Azure Groups

1.4

Azure Network Security Groups

2.2

Azure Resource Groups

1.5

Azure Resource Subscriptions

5

Azure Resources

1.6

Azure Roles

1.4

Azure Service Principals

1.5

Azure Tenants

2.8

Azure Users

3.4

Azure Virtual Machines

2.5

Disk Space for Active Roles Event Data

An index entry for a single Active Roles event in IT Security Search Warehouse takes 0.5KB on average. Estimate the event rate in your environment to calculate the required disk space.

Disk Space for InTrust and Change Auditor Data

To display InTrust and Change Auditor events, IT Security Search uses the built-in indexes in InTrust and Change Auditor data stores, so no additional disk space is required.

 

Where to Install

It is recommended that you install IT Security Search in the same domain as the servers of your data-providing systems: InTrust, Enterprise Reporter, Change Auditor, Active Roles and Recovery Manager for Active Directory. Do not install IT Security Search on any of those systems' servers.

Caution:

  • When you specify the organization and configuration database for the Warehouse component during installation of a new instance of IT Security Search, do not select an existing InTrust or Warehouse organization or configuration database. If you do, that database can become corrupted. Always create a new organization and configuration database for each instance.
  • Conversely, if you are upgrading IT Security Search, let setup reuse the existing configuration settings.

What Accounts to Use

In the course of IT Security Search setup, you create the Warehouse configuration database. Make sure you run setup under an account that has sufficient privileges to create databases on your SQL server.

Setup also prompts you to specify the accounts to use for the following:

  • Warehouse server account configuration
  • Warehouse API installation

For smooth IT Security Search operation, it is recommended that you specify a single account that is configured as follows:

  1. Membership in the Administrators computer local group on the computer where you want to install IT Security Search.
  2. DBO access to the Warehouse configuration database.
  3. Full Control access to the network shares that you want to use as Warehouse stores.

You should create or appoint this account in advance. After IT Security Search installation, ensure that the account has the privileges listed above.

IMPORTANT: If you use SQL Server authentication for access to the Warehouse configuration database, the SQL Server account's password should be set to never expire.

Security Details and Configuration

By default, IT Security Search uses a self-signed SSL certificate, which will cause security errors for IT Security Search users. You can provide a new certificate at any time. Your certificate can be either self-signed or issued by a certificate authority. Using a certificate generated by your organization and signed by a certificate authority is recommended.

Providing a CA-Signed Certificate

If your company uses a registered SSL certificate, run the New-CertificateBinding.ps1 PowerShell script described below to make IT Security Search use the certificate.

You can obtain a CA-signed certificate using Windows native tools and then bind it, as follows:

  1. Log on to the IT Security Search server using an IT Security Search administrator account.
  2. Run Microsoft Management Console (mmc.exe) and add the Certificates snap-in.
  3. Select Computer Account and click Next.
  4. Select Local Computer, and then Finish.
  5. Click OK in the Add or Remove Snap-ins dialog box.
  6. In the console, right-click Certificates (Local Computer)| Personal | Certificates and select Request New Certificate to start the Certificate Enrollment wizard.
  7. Click Next and Next again to use the Active Directory Enrollment Policy.
  8. Locate the Web Server certificate template and clear its check box. If you cannot see this template, make the check box to show all templates is selected. If you can see the template but don't have permission to enroll, contact your Certicate Authority administrator to be granted the Enroll permission for the account of the computer where IT Security Search is installed.
  9. Click the More information is required to enroll for this certificate link.
  10. On the Subject tab, from the drop-down menu under Subject name select Common Name and enter the NetBIOS name of the IT Security Search server. Click Add.
  11. From the drop-down menu under Alternative name, select DNS and enter the NetBIOS of the IT Security Search server. Click Add.
  12. From the drop-down menu under Alternative name, select DNS and enter the FQDN of the IT Security Search server. Click Add.
  13. Change the drop-down menu to IP address (v4) and the IP address will be automatically supplied. Click Add.
  14. Change the drop-down menu to IP address (v6). If IPv6 is enabled, the IP address will also be automatically supplied. Click Add. If nothing is supplied, you can safely skip this step.
  15. In the same section, if necessary, enter any predefined names that DNS records have been created for, such as "IT Security Search Console", so the certificate matches the name of the URL used for access to the page.
  16. Go to the General tab and enter a Friendly name, for example IT Security Search Certificate. Optionally, add a description.
  17. Go to the Extensions tab, expand Extended Key Usage and confirm that Server Authentication is available appears under Selected options.
  18. Click Apply, then click OK, then click Enroll.
  19. The new certificate should now appear in the Certificates folder, under Personal.
  20. Export the certificate by right clicking it and selecting All Tasks | Export.
  21. In the Certificate Export wizard, click Next.
  22. On the next step, make sure the No, do not export the private key radio button is selected. Click Next.
  23. Select the DER encoded binary X.509 (.CER) radio button and then click Next.
  24. Click Browse to select where to save the certificate. For example, save it in %ProgramFiles%\Quest\IT Security Search and give the file a descriptive name.
  25. Click Next and then click Finish. The certificate is saved at the specified location.
  26. To make IT Security Search use this new certificate, run the New-CertificateBinding.ps1 script as described below, supplying the file you saved on the previous step.

Providing a Self-Signed Certificate

To create a new self-signed certificate, use the New-SslCertificate.ps1 PowerShell cmdlet located in the Scripts subfolder of your IT Security Search installation folder. By default, the certificate is set to be in effect from the current date until December 31, 2039.

The cmdlet has the following parameters:

Parameter Type Description

-FilePath

string

The path to your certificate file.

-Subject

string

The subject of the certificate.

-SubjectDnsAltNames

string

Optional: a list of alternative names for the IT Security Search server (IP addresses, NetBIOS name and so on). If this parameter is omitted, the certificate will be generated for all possible alternative names of the specified host (IPv4 address, IPv6 address, FQDN, NetBIOS, but not for localhost or 127.0.0.1).

-Begin

datetime

Optional: the date from which the certificate is in effect; by default, from the current day.

-End

datetime

Optional: the date until which the certificate is in effect; by default, until December 31, 2039.

-KeepExisting

switch

Whether any existing file with the specified name should be kept instead of overwritten.

Example:

powershell -file "C:\Program Files\Quest\IT Security Search\Scripts\New-SslCertificate.ps1" -filepath "c:\temp\ITSearch.cer"

After you have generated the certificate (and ideally, had it signed by a CA), perform the procedure described in Binding Your Certificate.

Binding Your Certificate

To begin using your self-signed or CA-signed certificate, use the New-CertificateBinding.ps1 cmdlet, which is located in the Scripts subfolder of your IT Security Search installation folder. The cmdlet has the following parameters:

Parameter Type Description

-FilePath

string

The path to your certificate file.

-Port

int

The port that IT Security Search uses. It is specified during setup, the default port is 443.

-Force

switch

If this switch is set, then any existing certificate will be unbound from the specified port. If the switch is not set, then the existing certificate will be kept instead of the specified one.

-FilePassword

SecureString

If your certificate is a password protected .PFX certificate, you need to provide this parameter.

-Thumbprint

string

The thumbprint of your certificate stored in Windows certificate store.

Examples:

powershell -file "C:\Program Files\Quest\IT Security Search\Scripts\New-CertificateBinding.ps1" -filepath "c:\temp\ITSearch.cer" -port 443 –Force

powershell -file "C:\Program Files\Quest\IT Security Search\Scripts\New-CertificateBinding.ps1" -thumbprint 'AAFBE587E91F0C81F6ED2FDD45F911AFF35C8E2D' -port 443 –Force

Revoking a Certificate

To revoke a certificate that is currently in use by IT Security Search, run the Delete-CertificateBinding.ps1 cmdlet located in the Scripts subfolder of your IT Security Search installation folder.

Example:

powershell.exe -file "C:\Program Files\Quest\IT Security Search\Scripts\Delete-CertificateBinding.ps1" -Port 443

The -Port parameter specifies the port that the certificate is bound to.

Caution: After you perform this operation, the IT Security Search service becomes unavailable until a new certificate is bound. Prepare the next certificate in advance to avoid downtime.

How IT Security Search Security Features Are Implemented

IT Security Search security is based on the Windows Data Protection API (DPAPI). For details about its security features, see the "Windows Data Protection" MSDN article; at the time of this writing it is located at https://msdn.microsoft.com/en-us/library/ms995355.aspx.

Enabling Secure Data Transfer for IT Security Search Warehouse

By default, IT Security Search Warehouse uses the insecure HTTP protocol. The steps below describe how to enable HTTPS for the Warehouse.

Caution: Before you begin, consider the following:

  • Functionality associated with IT Security Search Warehouse will be unavailable during the switch.
  • The procedure should be performed at a time when Enterprise Reporter is not pushing data. Choose a time between discoveries, and confirm that all data from the latest discovery has been sent.
  • We recommend stopping the Quest IT Security Search and Quest IT Security Search Active Roles Data Attendant services on the IT Security Search server for the duration of the switch to HTTPS.

To switch IT Security Search Warehouse to using HTTPS

  1. (Conditional) Provide a CA-signed certificate, as described in Providing a CA-Signed Certificate above. If you have already installed such a certificate for use on port 443, you can skip this step.
  2. In the Scripts subfolder of your IT Security Search Warehouse API installation folder, locate the Enable-SecureEndpoint.ps1 script.
  3. Run this script in PowerShell in Administrator mode. For the -thumbprint parameter, specify the thumbprint of your existing certificate in the certificate store. If you omit the -port parameter, the script makes the Warehouse share port 443 with IT Security Search.
    Example:
    powershell -file "C:\Program Files\Quest\IT Security Search Warehouse\Scripts\Enable-SecureEndpoint.ps1" -thumbprint 'AAFBE587E91F0C81F6ED2FDD45F911AFF35C8E2D' -port 443
  4. Start or restart the Quest IT Security Search and Quest IT Security Search Active Roles Data Attendant services.

After you have completed these steps:

  • Confirm that the Warehouse and Active Roles connectors are working. For that go to those connectors' settings and click Test Connection.
  • If you use Enterprise Reporter data, open Enterprise Reporter Configuration Manager and enable secure connection to IT Search Warehouse. For more details, see Enterprise Reporter documentation.

Running IT Security Search Services Under a Group Managed Service Account (gMSA)

To set up a gMSA to run IT Security Search services, you need to perform a few configuration procedures, as explained below.

Make the gMSA a Server Administrator

Your gMSA must have local administrative rights on the computer where IT Security Search is installed. Make sure the gMSA is in the local Administrators group on the computer.

Set Up Password Retrieval

You need to use PowerShell to allow your gMSA to retrieve the managed password from the domain controller.

In the PowerShell prompt, run the following commands (assuming that the name of your gMSA is my_gmsa):

Add-WindowsFeature RSAT-AD-PowerShell

Install-ADServiceAccount -Identity my_gmsa

Set the Service Account

The following steps need to be taken for each of the following services:

  • ITSS.Server
  • ITSS.DataAttendant.ActiveRoles
  • ITSS.Warehouse

To set the gMSA for a service

  1. Open the properties of the service.
  2. On the Log On tab, select This account and specify your gMSA in domain\user$ format. The dollar sign at the end is required. For example, if your gMSA is my_domain\my_gmsa, then type my_domain\my_gmsa$. Leave the password fields empty.

NOTE: When the service is configured, you may get a message that the account has been granted the “Log On As a Service” right.

  1. Restart the service.
Finalize Warehouse Reconfiguration

Finally, configure the InTrust Server service (adcrpcs) to use this gMSA, as described in Minimal Rights and Permissions Required for InTrust Operations.

Who Can Do What in IT Security Search

There are two roles that IT Security Search associates with users that access it: operator and administrator. Unless your user account is one of these, you do not have access to IT Security Search.

Each operator has a scope of responsibility, which defines which features the operator can use. To make an account an operator, include it in the IT Security Search access control list. This list is available on the IT Security Search Settings page, on the Security tab. You can supply individual users in domain\user format or security groups in domain\group format.

An administrator can do the following:

  • Search everywhere
  • Perform Active Directory recovery if the Recovery Manager data link is enabled
  • Configure the connectors to the data-providing and operations management systems, as described in Where the Data Comes From
  • Assign operator roles

To give a user account administrator privileges, make the account a member of the IT Security Search Administrators local group on the computer where IT Security Search is installed. You can assign the administrator role by specifying Active Directory groups or individual users. If an account is an administrator and an operator at once, the administrative privileges take precedence and the account's operator scope has no meaning.

The user account that performs IT Security Search installation automatically becomes an administrator.

Setting the Scope of Responsibility for an Operator

For each operator you add, specify the scope of objects visible to the operator by supplying a list of organizational units. In addition, you can further tweak the scope by specifying a search query. The resulting scope is the OR-based union of the results of the list and the query.

If you want to make everything visible to an operator, leave the list and query empty (for the OU list, specifying the asterisk wildcard * also has the same effect). If you want to limit an operator's scope, follow the instructions below.

Caution:

If you use an asterisk for the OU list or leave it empty, InTrust events will not be affected by the scope delegation settings. All operators can see all InTrust events in this case.

If the OU list specifies OUs, InTrust events will be returned only if the Enterprise Reporter connector is enabled and configured.

Creating the List of OUs

To make the right decisions when specifying OUs, make sure you understand the relevance of these OUs to the results that the operator is going to get. The following table explains how the choice of OU affects the scope, depending on the type of object:

What type of object the operator looks for

The operator sees the object if...

Active Directory user, group or computer

It is in the OU (or any OU nested in it)

OU

It is the same OU or it is nested in the OU at any level

Computer that isn't in a domain

Computer local user or group

The computer is in the OU (or any OU nested in it)

File or network share

The hosting computer is in the OU (or any OU nested in it)

InTrust event

If the OU list is empty or an asterisk, scope settings are irrelevant and the operator can see all InTrust events.

If the Enterprise Reporter connector is enabled and the OU list specifies OUs:

  • If the event has the Whom field, the operator sees it as long as the OU (or any OU nested in it) contains the object in Whom
  • Otherwise, the operator sees it as long as the OU (or any OU nested in it) contains the object in Where
Non-InTrust event
  • If the event has the Whom field, the operator sees it as long as the OU (or any OU nested in it) contains the object in Whom
  • Otherwise, the operator sees it as long as the OU (or any OU nested in it) contains the object in Where

The OUs must be listed in canonical name format, one OU per line.

Fine-Tuning the Scope with Queries

The queries you specify return not just OUs but any objects with the specified field values. You can supply any query that follows IT Security Search syntax conventions. For details, see Search Term Syntax.

IMPORTANT:

  • The results will contain objects that match the OU list, the query, or both. For example, if the query returns an object from an OU that isn't listed, the object is included in the results anyway.
  • Functions such as MemberOf and Members_Deep don't work in queries specified here.

Filtering by OU is not applicable to data from Azure, because Azure objects aren't organized into OUs. If you are interested in Azure objects, a good way to get them is to use a query that contains the Tenant field.

Use the Test query action link to make sure your query is valid and returns what you need. Note that the OU list doesn't affect the results of Test query.

Auto-Lookup of Operator Data in a Query

To quickly supply the identifying details of an operator without looking them up in Active Directory, you can use the {Context.CurrentUser} variable as a field value. Alternatively, you can access specific identifying fields for the operator's account using syntax such as {Context.CurrentUser.FullAccountName} or {Context.CurrentUser.AccountSid}. For details about this technique, see the Auto-Resolution of the Current User section of the Search Term Syntax topic.

If you specify a group (instead of a user) as an operator, then the resolution works for all members of the group (direct or indirect) when they use IT Security Search.

Queries containing the variable are stored as supplied, and the variables are resolved only when the queries are applied. Therefore, the resulting identifying data is always up to date.

Examples

OU list

Query

Details

 

FacilityName:AD AND What="user changed"

Searches by an operator with this scope will return all events of the "user changed" type from Active Directory.

OU1

OU2

"Tenant=T1 OR Tenant:T2"

Searches by an operator with this scope will return all objects related to OU1, all objects related to OU2, all objects where the Tenant field equals "T1" and all objects whose Tenant field contains "T2".

OU3

"Tenant=T3"

Searches by this operator will return all objects related to OU3 and all objects whose Tenant field equals "T3".

If the scope is defined for a group and the operator from the previous example is a member of that group, then that operator's scope is extended and becomes: all objects related to OU1, OU2 or OU3, all objects where the Tenant field equals "T1" or "T3" and all objects whose Tenant field contains "T2".

OU4

Eventid=4740

Searches by this operator will return all objects related to OU4 and all events (no matter if related to the listed OUs) with event ID 4740.

Controlling Active Directory Recovery Privileges

In addition to visibility scope, you can configure which operators can restore Active Directory objects. For that, use the Restore backups option in the Allowed Operations column of the table. The actual recovery functionality is provided by the Recovery Manager for Active Directory connector. For details, see Recovery Manager for Active Directory Server.

Self Service Tools
Knowledge Base
Notifications & Alerts
Product Support
Software Downloads
Technical Documentation
User Forums
Video Tutorials
Contact Us
Licensing Assistance
Technical Support
View All
Related Documents