Chapter 3: IDA Management

Home Prev	IDA Version 1.07.03 Administration Guide

The IDA Management Interface

The IDA service listens for authenticated users and sends their details to the configured Clavister Next Generation Firewall. The IDA service has its own management user interface and this interface has a number of tabs which are described below.

The General tab

This tab consists of the following settings:
1. Listening IP - This is the IPv4 address and port number which the IDA will listen on for connections to cOS Core. By default, the IDA will listen on port 9999 of 0.0.0.0/0, which means any IPv4 address. Multiple IP values can be entered for this setting and must include the IP configured for the cOS Core Authentication Agent object of the connecting firewall.
2. Remote Desktop IP Virtualization - This allows IDA to be used with a Windows Terminal Server™. This feature is described in detail later in this section.
3. User Timeout - This is the time within which cOS Core must authenticate the user after they are authenticated by the Windows server.
4. Global Catalog Query - By default, only the active directory is queried for the user. If this option is enabled and the active directory search fails then the global catalog will be queried.

Figure 3.1. The General Tab in the IDA Interface

The Event Monitoring tab

This tab consists of the following settings:
1. Monitor the local event log - When enabled, this IDA installation will monitor the server on which it is installed for authentication events. Usually, this will be enabled since normally the agent will monitor events on its own server.
2. Remote monitoring - This specifies the IP address of other domain servers which are to be monitored by this IDA installation. More than one IDA installation can monitor the same domain server and more than one IDA installation can send the same authentication event to cOS Core (duplicate received IDA events are recognized by cOS Core and ignored).
If the Monitor the local event log option is not enabled and no other server IP addresses are specified, the agent will send nothing back to cOS Core.

Figure 3.2. The Event Monitoring Tab in the IDA Interface

The Security tab

This tab consists of the following settings:
1. Encryption key - This is the key used to encrypt communication with cOS Core. By default, this value will be the same as the default value of the Pre-Shared Key property of the corresponding cOS Core Authentication Agent object. For improved security, it is recommended that this key is changed by the administrator, both for the IDA and the corresponding cOS Core Authentication Agent object. The key must be specified as a 256 bit hexadecimal value.
2. Restrict IPs/networks to - This specifies the source IPv4 addresses from which the IDA will accept cOS Core connections. By default, all IPv4 addresses will be accepted.

Figure 3.3. The Security Tab in the IDA Interface

The Excluded Users tab

In this tab, it is possible to set up an exclusion list for the IDA so that users on the list will not have their authentication status sent back to cOS Core by the IDA service. The full User Principal Name (UPN) must be used to specify excluded users, for example:
```
		myusername@mydomainname.local
```
Often, it is appropriate to include the administrator's own account on this exclusion list.

Figure 3.4. The Excluded Users Tab in the IDA Interface

When specifying excluded users, either or both of the following two wildcard characters can be used in any part of an address:

* - An asterisk character can represent any character string. For example:

		somename1@example.*

? - A question mark character can represent any single character. For example:

		somename?@example.*

The IP Filtering tab

This tab allows the IP address of the authenticating client to be filtered using a list of filtering rules. Each rule added to the list by the administrator consists of an IP address, network or IP range, along with an action of either Allow or Deny.

When the IDA processes a new client login, it scans the rule list from top to bottom and stops scanning at the first match for the client's IP address. If the action for the matching rule is Allow, the login is sent to cOS Core as normal. If the action is Deny, the login is ignored and no message is sent to cOS Core.

If no match for the IP is found in the list, or the list is empty, the Default Action setting is applied. This setting is Allow by default.

An empty list (the default) with the Default Action set to Allow means that all client IP addresses are allowed.

Figure 3.5. The IP Filtering Tab in the IDA Interface

An Example of IDA Redundancy

To illustrate how IDA redundancy could be implemented, consider a domain that has 4 servers called A, B, C and D. To implement minimal redundancy, the steps would be as follows:

Install the IDA on server A and server B.
Enable the Event Monitoring for both installations so they are monitoring local server authentication events.
For server A, configure the Remote monitoring option with the IP addresses of servers B, C and D so that they are monitored too.
For server B, configure the Remote monitoring option with the IP addresses of servers A, C and D so that they are monitored too.

Now, if either server A or B should fail, authentication events will still be sent back to cOS Core. cOS Core will recognize any duplicate events sent by both server A and server B.

Using IDA with a Windows Terminal Server

In some environments, a Terminal Server may be used as well as a domain server. If this is the case, the IDA service is installed as before but the option Remote Desktop IP Virtualization should be enabled.

However, IP virtualization will not function with either Windows 2012 or 2016 Server if the IDA software is running as a Local System account. To solve this issue, change the settings in the Log On tab for the server to This Account and specify an account, as shown below:

Figure 3.6. Changing Windows 2012/16 Settings for IP Virtualization

The terminal server itself must have the following attributes:

The role Remote Desktop Session Host must be installed.
The option IP virtualization per session must be enabled.

	Note: DNS lookup is done using the terminal server IP
	Any DNS lookups are performed using the IP of the Windows terminal server and not the session IP assigned to the client. Therefore, IP rules or IP policies may be needed to allow such DNS lookups through the firewall.