IDA Version 1.07.03 Administration Guide

Table of Contents

1. IDA Overview
2. IDA Installation
3. IDA Management

Chapter 1: IDA Overview

	Note: This document is also available in other formats
A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com. It is also available in a framed HTML version.

Note: This document is also available in other formats

A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com.

It is also available in a framed HTML version.

Introduction

This guide describes the installation and administration of the Identity Awareness Agent (IDA) software. The IDA software is a component of the cOS Core identity awareness feature which is used for authentication of remote clients. This guide can be seen as an extension of the identity awareness description which can be found in the authentication section of the cOS Core Administration Guide.

The Software is Separate to cOS Core

The IDA software is not supplied with cOS Core as it is a piece of self-contained software. Instead, it must be downloaded separately from the Clavister website. The IDA software version numbering is also different from cOS Core version numbering and new IDA versions may be released at any time.

The Software Runs On Windows Domain Servers

The IDA software runs on one or more Windows domain servers in an active directory, sending back authenticated client information to cOS Core so that further authentication is not necessary. The IDA can run on either a domain controller or domain member. Installation of the IDA software on multiple servers will provide redundancy.

Compatible Windows Server Versions

The IDA software can be installed only on Windows Server™ 2008 R2, 2012 or 2016.

Detailed guidelines for installation are described in the next chapter.

Chapter 2: IDA Installation

The latest IDA software release can be downloaded from the Clavister website. The installation file is a self-extracting Windows executable. When the IDA software is installed, it runs as a Windows service called IDA.exe.

IDA Installation Requirements

The following should be noted when installing the IDA:

When installing the IDA software, the user must have administrator privileges.

When the IDA software is installed on a server that is not an Active Directory Domain Controller, it must be started using an account that has the privileges to allow the reading of the Security Event Log of the Domain Controller.

It is recommended to run the IDA software at a lower priority than other processes.

The IDA software must have permissions to do the following:

Read from the event log. To do this a user must be a member of the Event Log Readers user group. This group can be found in the Builtin Active Directory container.
Query the Active Directory for users and groups.

	Note: Replacement of spaces in cOS Core group names
	A group name on the domain controller server can contain spaces. With cOS Core versions prior to 13.00.11, spaces in the name must be replaced by the underscore character "_". Starting with cOS Core version 13.00.11, space replacement is no longer required.

The IDA software can also run as the Local System account.

If the Remote Event Log Monitoring feature is required, an account for the computer where IDA is installed should be added to the Event Log Readers user group.

	Note: Troubleshooting installation issues
	If there are issues which occur during installation of the IDA and the problem is not immediately clear, it can be useful to open the Windows Event Viewer and examine recent entries.

Deployment in Medium to Large Infrastructure Environments

If an environment has two domain controllers, it is recommended to install the IDA software on each domain controller and set them up to monitor the local Windows Event Log.

In an environment with a larger infrastructure, there is no need to install the IDA software on every single domain controller. Instead, remote Windows Event Log monitoring should be enabled.

If there are multiple sites in different geographic locations, it is highly recommended to have the IDA software installed in each local network.

	Important: The Windows Server event IDs must be correct
The Clavister IDA software will only listen for certain event IDs so the Windows Server should be configured so that the correct IDs are generated. The IDs that the IDA listens for are the following: 103 - An RDP user has logged in and has been assigned a virtual IP. 104 - An RDP user has logged out and the user’s IP has been released. 4624 - An account was successfully logged on. 4728 - Member added to global group. 4729 - Member removed from global group. 4756 - Member added to universal group. 4757 - Member removed from universal group. 4732 - A user has been added to a local domain group. 4733 - A user has been removed from a local domain group. 4768 - A user has logged in.

Important: The Windows Server event IDs must be correct

The Clavister IDA software will only listen for certain event IDs so the Windows Server should be configured so that the correct IDs are generated. The IDs that the IDA listens for are the following:

103 - An RDP user has logged in and has been assigned a virtual IP.
104 - An RDP user has logged out and the user’s IP has been released.
4624 - An account was successfully logged on.
4728 - Member added to global group.
4729 - Member removed from global group.
4756 - Member added to universal group.
4757 - Member removed from universal group.
4732 - A user has been added to a local domain group.
4733 - A user has been removed from a local domain group.
4768 - A user has logged in.

Chapter 3: IDA Management

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.