Users and Devices


Users and Groups

Security policies, firewall rules, safe browsing rules, and many other features of UserGate NGFW can be applied to users or user groups. The ability to apply policies only to the relevant users gives the administrator the flexibility to configure the network to the organization's requirements.

User identification is a fundamental part of NGFW functionality. A user is considered identified if the system has unambiguously associated the user with the IP address of the device they use to connect to the network. NGFW uses different user identification mechanisms:

  • Explicitly defined IP address

  • Login name and password

  • Dedicated terminal server agent (for Microsoft Terminal Server user identification)

  • Authorization agent (for Windows systems)

  • NTLM or Kerberos protocol.

User identification using name and password can be performed via the captive portal, which in turn can be configured to identify users with the help of Active Directory, RADIUS, TACACS+, NTLM or Kerberos directories or a local user database.

The following user types are defined in NGFW:

Name

Description

Unknown user

Represents the set of users not identified by the system.

Known user

Represents the set of users identified by the system. The methods of user identification can differ and will be described in more detail later in this chapter.

Any user

This is a union of the Known and Unknown user sets.

Specific user

A specific user defined and identified in the system; e.g., DOMAIN\User, identified using Active Directory domain authorization.

Users and groups can be added on the NGFW device itself (these are known as local users and groups) or obtained from external directories, such as Microsoft Active Directory.

Groups

User groups enable distinct sets of users to be defined for easier security policy management.

Users

In this section, you can add local users as well as temporarily disable or re-enable them.

The required settings for creating a local user are the username and login. The rest of the settings are optional, but for correct identification, the following must be provided:

  • Login and password --- for identification using a name and password. In this case, you will need to configure the captive portal where a user can enter their login name and password for authentication.

  • IP address, IP address range, or MAC address --- for identification using a combination of MAC and IP addresses. Here you need to make sure that the user always accesses the network from the specified MAC and/or IP address.

  • VLAN ID --- for identification using a VLAN tag. In this case, you need to make sure that the user always accesses the network from the specified VLAN.

  • Email: the user's email address. If specified, this can be used to send information, such as a 2nd authentication factor, to the user by email.

  • Phones: the user's phone numbers. If specified, this can be used to send information, such as a 2nd authentication factor, to the user by SMS.

If both login/password and IP/MAC/VLAN addresses are specified for the user, the system uses address-based identification. In other words, address-based identification takes priority.

LDAP user accounts are not displayed here, but these users can also be used in security policies.


Authentication Servers

Authentication servers (auth servers) are external sources of user accounts, such as an LDAP server, or servers that perform authentication for NGFW, such as RADIUS, TACACS+, Kerberos, or SAML. The system supports the following types of authentication servers:

RADIUS, TACACS+, NTLM, and SAML authentication servers can only authenticate users, while a LDAP connector also makes it possible to obtain information on users and their properties.

LDAP Connector

An LDAP connector allows you to:

  • Obtain information on users and groups from Active Directory or other LDAP servers. FreeIPA is supported with an LDAP server. The users and groups can be used in filtering rules.

  • Authorize users via Active Directory/FreeIPA domains using the captive portal, Kerberos, and NTLM authentication methods.

To create an LDAP connector, click Add, select Add LDAP connector, and provide the following settings:

Name

Description

Enabled

Enables or disables the use of this authentication server.

Name

The name of the authentication server.

SSL

This specifies whether SSL is required to connect to the LDAP server.

LDAP domain name or IP address

The IP address of the domain controller, the domain controller FQDN or the domain FQDN (e.g., test.local). The IP address of the domain controller, the domain controller FQDN or the domain FQDN (e.g., test.local). Если указан FQDN, то NGFW получит адрес контроллера домена с помощью DNS-запроса.

Bind DN ("login")

The username for connecting to the LDAP server. Must be in the DOMAIN\username or username@domain format. This user must be already created in the domain.

Password

The user's password for connecting to the domain.

LDAP domains

The list of domains served by the specified domain controller, e.g., in case of a domain tree or an Active Directory domain forest. Here you can also specify the short NetBIOS domain name. The domains listed here will be available for selection on the captive portal's auth page if the corresponding option is enabled. For more details on configuring the captive portal, see the Captive Portal Configuration section.

Search roots

The list of LDAP server paths relative to which the system will search for users and groups. Specify the full name, e.g., ou=Office,dc=example,dc=com.

Kerberos keytab

Here you can upload a keytab file for Kerberos authentication. For more details on Kerberos authentication and creating a keytab file, see the Kerberos Authentication Method section.

Important! Uploading a keytab file is recommended even if you do not plan to use Kerberos authentication. With an uploaded keytab file, NGFW uses the Kerberos mechanism to obtain the list of users and their groups from LDAP servers, which dramatically reduces the load on the LDAP servers. If the LDAP servers in your organization store a large number of objects (more than 1000 groups and users), using a keytab file is strongly encouraged.

After creating a server, you should validate the settings by clicking Check connection. If your settings are correct, the system will report that; otherwise, it will tell you why it cannot connect.

Note To gain authorization using an LDAP connector, the users must be members of the "Domain users" domain group.

The LDAP connector configuration is now complete. For LDAP user authorization using a name and password, you need to create captive portal rules. The captive portal is described in more detail in the following chapters.

To add an LDAP user or user group to the filtering rules, click Add LDAP user/Add LDAP group, type at least one character present in the names of the desired objects in the search field, and then click Search and select the users or groups of interest.

RADIUS User Authentication Server

The RADIUS option enables user authentication on RADIUS servers, with NGFW working as a RADIUS client. When authorization is done using a RADIUS server, NGFW sends the username and password information to the RADIUS server, which then responds as to whether or not the authentication was successful.

A RADIUS server cannot provide a list of users to NGFW, therefore, if the users were not added to NGFW in advance (e.g., as local users or users fetched from an AD domain using an LDAP connector), only users of types Known (those who successfully authenticated with the RADIUS server) and Unknown (those who were not authorized) can be used in filtering policies.

To add a RADIUS authentication server, click Add, select Add RADIUS server, and provide the following settings:

Name

Description

Enabled

Enables or disables the use of this authentication server.

Server Name

The name of the authentication server.

Shared secret

Pre-shared key used by the RADIUS protocol for authentication.

Host

The IP address for the RADIUS server.

Port

The UDP port on which the RADIUS server listens for authentication requests. By default, UDP port 1812 is used.

After adding the authentication server, you need to configure the captive portal for using the RADIUS method. The captive portal is described in more detail in the following chapters.

TACACS+ User Authentication Server

The TACACS+ option enables user authentication on TACACS+ servers. When authorization is done using a TACACS+ server, NGFW sends the username and password information to the server, which then responds as to whether the authentication was successful.

A TACACS+ server cannot provide a list of users to NGFW, therefore, if the users were not added to NGFW in advance (e.g., as local users or users fetched from an AD domain using an LDAP connector), only users of types Known (those who successfully authenticated with the TACACS+ server) and Unknown (those who were not authorized) can be used in filtering policies.

To add a TACACS+ authentication server, click Add, select Add TACACS+ server, and provide the following settings:

Name

Description

Enabled

Enables or disables the use of this authentication server.

Server Name

The name of the authentication server.

Secret

Pre-shared key used by the TACACS+ protocol for authentication.

Address

The IP address for the TACACS+ server.

Port

The UDP port on which the TACACS+ server listens for authentication requests. By default, UDP port 1812 is used.

Use single TCP connection

Use a single TCP connection for communicating with the TACACS+ server.

Timeout (sec.)

The authentication timeout for the TACACS+ server. The default is 4 seconds.

SAML IDP User Authentication Server

The SAML IDP (Security Assertion Markup Language Identity Provider) option enables user authorization using a Single Sign-On (SSO) system deployed in the organization, such as Microsoft Active Directory Federation Service. With this method, a user who has been authorized in the SSO system (and not logged out since) will be transparently authorized on all resources that support SAML authentication. NGFW can be configured as a SAML service provider that uses SAML IDP servers for client authorization.

A SAML IDP server cannot provide a list of local user properties to NGFW, therefore, if you have not configured AD domain connection through an LDAP connector, only users of types Known (those who successfully authenticated with the SAML server) and Unknown (those who were not authenticated) can be used in filtering policies.

To configure authorization using an SAML IDP server, follow these steps:

Name

Description

Step 1. Create DNS records for NGFW.

On the domain controller, create a DNS record corresponding to NGFW to be used as the auth.captive domain (e.g., utm.domain.loc). Point it to the IP address of a NGFW interface connected to the Trusted network.

Step 2. Configure DNS servers in NGFW.

In the NGFW settings, set the domain controller's IP addresses as the system DNS servers.

Step 3. Change the Captive portal auth domain address.

In the General settings section, change the Captive portal auth domain address to the DNS record created in the previous step. For more details on changing the captive portal's Auth domain address, see the General Settings section.

Step 4. Configure the SAML IDP server.

On the SAML IDP server, add a record on the NGFW service provider specifying the FQDN created at Step 1.

Step 5. Create the SAML IDP user authentication server.

Create the SAML IDP user authentication server in NGFW.

To do that, go to the Users and devices ➜ Auth servers section, click Add, select Add SAML IDP server and provide the following settings:

Name

Description

Enabled

Enables or disables the use of this authentication server.

Server Name

The name of the authentication server.

Description

Auth server description.

SAML metadata URL

The URL on the SAML IDP server from where an XML file with a valid configuration for this SAML service provider (client) can be downloaded. When you click Upload, the relevant authentication server settings fields will be populated with the data from that XML file. This is the preferred method of configuring a SAML IDP authentication server. For more details, see the documentation for the SAML IDP server that you use.

SAML IDP certificate

The certificate that will be used on the SAML client. The available options are:

  • Create new certificate from downloaded: if the XML upload method was used to configure the server, a new certificate is automatically created and assigned the SAML IDP role (see the Certificate Management section).

  • Use existing certificate. The certificate must have already been created or imported in the Certificates section and must not have a role assigned to it. After you add and save the authentication server, this certificate will be assigned the SAML IDP role.

  • Do not use certificate.

Single sign-on URL

The URL that is used on the SAML IDP server as the single login point. For more details, see the documentation for your SAML IDP server.

Single sign-on binding

The method used to work with a SSO single login point. Options: POST and Redirect. For more details, see the documentation for your SAML IDP server.

Single logout URL

The URL used on the SAML IDP server as the single logout point. For more details, see the documentation for your SAML IDP server.

Single logout binding

The method used to work with a SSO single logout point. Options: POST and Redirect. For more details, see the documentation for your SAML IDP server.

NTLM Authentication Server

The NTLM option enables transparent (i.e., without requesting a username and password) authorization of Active Directory domain users. With NTLM authorization, NGFW works with the domain controllers that authenticate the user for Internet access.

An NTLM server cannot provide a list of users to NGFW, therefore, if the users were not added to NGFW in advance (e.g., as local users or users fetched from an AD domain using an LDAP connector), only users of types Known (those who successfully authenticated with the NTLM server) and Unknown (those who were not authenticated) can be used in filtering policies.

NTLM authentication can work both with a proxy explicitly set in the user's browser (this is the standard mode) and in the transparent mode with no proxy set in the browser. NGFW is configured identically in both authorization modes.

To configure authorization using an NTLM server, follow these steps:

Name

Description

Step 1. Configure time synchronization with the domain controller.

In NGFW settings, enable time synchronization with NTP servers. Specify the IP addresses of the domain controllers as the primary and (optionally) secondary NTP server.

Step 2. Create a DNS record for NGFW.

On the domain controller, create DNS records corresponding to NGFW to be used as the auth.captive and logout.captive domains (e.g., auth.domain.loc and logout.domain.loc).

Point it to the IP address of a NGFW interface connected to the Trusted network.

Step 3. Change the Captive portal auth domain address.

In the General settings section, change the Captive portal auth domain and (optionally) Captive portal logout domain addresses.

For the Captive portal auth domain, specify the DNS record created at the previous step.

For the Captive portal logout domain, specify the DNS record created at the previous step.

For more details on changing the addresses of the captive portal's Auth and Logout domains, see the Captive Portal Configuration section.

Step 4. Add an NTLM server.

In the Auth servers section, click Add, select Add NTLM server, and specify the display name for the server and Windows domain name. For NTLM authentication to work correctly, the domain name specified here must resolve into the IP addresses of the domain controllers.

Step 5. Create a captive portal rule with NTLM authentication.

Configure the captive portal for using the NTLM authentication method. The captive portal is described in more detail in the following chapters.

Step 6. Enable HTTP(S) service access for the zone.

In the Zones section, enable access to the HTTP(S) proxy service for the zone to which the users who are authorized using NTLM are connected.

Step 7. For standard-mode authorization, configure the proxy on the user computers.

On the user computers, turn on mandatory proxy use and specify the IP address of a Trusted interface of NGFW as the proxy address.

Important! You can use a domain name instead of an IP address, but the important thing for NTLM is that this name should not come from the Active Directory domain, otherwise the Windows computer will try to use Kerberos authentication.

Important! The names used as the auth.captive and logout.captive domain in UserGate settings should not come from the Active Directory domain, otherwise the Windows computer will try to use Kerberos authentication.

Step 8. For transparent-mode authorization, configure automatic browser-based user authentication for all zones.

On user computers, go to Control panel ➜ Internet options ➜ Security, select the Internet zone ➜ Custom level ➜ User Authentication ➜ Logon and choose Automatic logon with current name and password.

Repeat this setting for all other zones configured on this computer (Local intranet, Trusted sites).

Kerberos Authentication Method

The Kerberos option enables transparent (i.e., without requesting a username and password) authorization of Active Directory domain users. When performing authorization via Kerberos, NGFW works with domain controllers that authenticate the user for Internet access.

Kerberos authentication can work both with a proxy explicitly set in the user's browser (this is the standard mode) and in the transparent mode with no proxy set in the browser.

To configure authorization using Kerberos, follow these steps:

Name

Description

Step 1. Create DNS records for NGFW.

On the domain controller, create DNS records corresponding to NGFW to be used as the auth.captive and logout.captive domains (e.g., auth.domain.loc and logout.domain.loc).

Point it to the IP address of a NGFW interface connected to the Trusted network.

Important! For correct operation, create type A records rather than CNAME.

Step 2. Create a user for NGFW.

Create a user in the AD domain, such as kerb@domain.loc, with the password never expires option. Set a password for user kerb.

Important! Do not use characters from national alphabets, such as Cyrillic, in the names of the kerb user or in the Active Directory organization units where you plan to create this user account.

Important! Do not use the user created for the LDAP connector as the kerb user. A separate user account needs to be used.

Step 3. Create a keytab file.

On the domain controller, create a keytab file by invoking the following command as an administrator (in one line!):

ktpass.exe /princ HTTP/auth.domain.loc@DOMAIN.LOC /mapuser kerb@DOMAIN.LOC /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass * /out C:\utm.keytab

Enter the password for user kerb.

Important! The command is case-sensitive. In the above example:

auth.domain.loc is the DNS record created for the UserGate server at Step 1;

DOMAIN.LOC is the Kerberos realm domain (UPPERCASE required!); and

kerb@DOMAIN.LOC is the username in the domain created at Step 2 (again, UPPERCASE required for the realm domain name!).

Step 4. Configure DNS servers in UserGate.

In the UserGate settings, set the domain controller's IP addresses as the system DNS servers.

Step 5. Configure time synchronization with the domain controller.

In UserGate settings, enable time synchronization with NTP servers. Specify the IP addresses of the domain controllers as the primary and (optionally) secondary NTP server.

Step 6. Change the Captive portal auth domain address.

In the General settings section, change the Captive portal auth domain and (optionally) Captive portal logout domain addresses to the DNS records created at the previous step. For more details on changing domain addresses, see the section General Settings.

Step 7. Create an LDAP connector and upload the keytab file to it.

Create an authentication server of type LDAP connector and upload the keytab file obtained at the previous step.

Important! Do not use the special Kerberos user created earlier as the user for the LDAP connector. A separate user account needs to be used.

For more details on configuring an LDAP connector, see the section LDAP Connector.

Step 8. Create a captive portal rule with Kerberos authentication.

Configure the captive portal for using the Kerberos authentication method. For more details on the captive portal, see the Captive Portal Configuration section.

Step 9. Enable HTTP(S) service access for the zone.

In the Zones section, enable access to the HTTP(S) proxy service for the zone to which the users authorized using Kerberos are connected.

Step 10. For standard-mode authorization, configure the proxy on the user computers.

On user computers, turn on mandatory proxy use and specify the proxy as the UserGate FQDN created at Step 3.

Step 11. For transparent-mode authorization, configure automatic browser-based user authentication for all zones.

On user computers, go to Control panel ➜ Internet options ➜ Security, select the Internet zone ➜ Custom level ➜ User Authentication ➜ Logon and choose Automatic logon with current name and password.

Repeat this setting for all other zones configured on this computer (Local intranet, Trusted sites).

HTTP Basic Authentication Method

The Basic option enables authorization of users with an explicitly set proxy using a local and LDAP user database. This authentication type is not recommended for use because it transmits the username and password over the network in plain text. The HTTP Basic authentication can be used to automatically authorize command-line utilities that need Internet access, for example:

curl -x 192.168.179.10:8090 -U user: password http://www.msn.com

To configure HTTP Basic authorization, follow these steps:

Name

Description

Step 1. Create a DNS record for NGFW.

On the domain controller, create DNS records corresponding to NGFW to be used as the auth.captive and logout.captive domains (e.g., auth.domain.loc and logout.domain.loc).

Point it to the IP address of a NGFW interface connected to the Trusted network.

Step 2. Change the Captive portal auth domain address.

In the General settings section, change the Captive portal auth domain and (optionally) Captive portal logout domain addresses.

For the Captive portal auth domain, specify the DNS record created at the previous step.

For the Captive portal logout domain, specify the DNS record created at the previous step.

For more details on changing the addresses of the captive portal's Auth and Logout domains, see the Captive Portal Configuration section.

Step 3. Create a captive portal rule with HTTP Basic authentication.

Configure the captive portal for using the HTTP Basic authentication method.

In addition to configuring the HTTP Basic method itself, you also need to add the user database that will be used for authentication (e.g., add the Local user or LDAP server authentication methods).

The captive portal is described in more detail in the following chapters.

Step 4. Enable HTTP(S) service access for the zone.

In the Zones section, enable access to the HTTP(S) proxy service for the zone to which the users authorized using HTTP Basic are connected.

Step 5. Configure a proxy on user computers.

On the user computers, turn on mandatory proxy use and specify the IP address of a Trusted interface of NGFW as the proxy address.


Authentication Profiles

An authentication profile can be used to specify a set of methods and settings for user authorization to be used later in various NGFW subsystems, such as captive portal, VPN, web portal, etc. To create an authentication profile, go to Users and Devices ➜ Auth profiles, click Add, and provide the desired settings:

Name

Description

Name

Profile name.

Description

Profile description.

MFA profile

The multi-factor authentication profile. This needs to be created in advance in the MFA profiles section if multi-factor authentication is to be used. The profile defines the method of one-time password delivery for the second authentication factor. For more details on configuring an MFA profile, see later in the corresponding chapter.

Important! Multi-factor authentication is only possible with authentication methods that allow the user to enter a one-time password, i.e., where the user explicitly enters their credentials in the auth page's web form. Therefore, multi-factor authentication cannot be used with Kerberos or NTLM.

Idle time

This parameter determines the time in seconds after which NGFW will re-classify the user from type Known to type Unknown when there is no activity from the user (no network packets coming from the user's IP address).

Expiration time

This parameter determines the time in seconds after which NGFW will re-classify the user from type Known to type Unknown. When this time elapses, the user will have to re-authenticate at the captive portal.

Maximum auth failures (local users)

The allowed number of failed authentication attempts via the captive portal after which the user account is locked.

Local user lockout time

The time for which the user account is locked on reaching the specified number of failed authentication attempts.

Authentication methods

The user authentication methods added earlier, for example, an Active Directory or RADIUS server. If there are multiple authentication methods, they will be used in the order they are listed in the console.

Built-in authentication mechanisms can also be used, such as:

  • Local user authentication: authentication using a local user database.

  • Policy accept: authentication is not required, but before the user is granted access to the Internet, they must consent to the network usage policy. This authentication type must be used in conjunction with a captive portal profile that uses a captive portal policy auth page.

  • HTTP Basic: authentication using the legacy HTTP Basic method.

  • Kerberos authentication: authentication using the Kerberos protocol.


Captive Portal Configuration

The captive portal makes it possible to authorize Unknown users with the help of authorization methods that use Active Directory, RADIUS, TACACS+, SAML IDP, Kerberos or NTLM directories or a local user database. Moreover, using the captive portal, you can configure user self-registration with email or SMS verification.

Remember that:

  • Identified users, such as those with an explicitly set IP address in the user profile or those identified using authorization agents for terminal servers or Windows systems, are not authorized at the captive portal. These users are already classified as Known and do not require further identification.

  • Captive portal authorization is only possible for HTTP and HTTPS protocols. For example, if you have created a firewall rule that allows Internet access using the FTP protocol only for Known users, users will not get Internet access using this protocol until they are identified; that is, they launch a browser on their device and pass authorization at the captive portal.

  • To authorize users that use HTTPS, you need to configure SSL inspection, or authorization will not work.

  • If the captive portal uses the Active Directory authorization method, the user must specify their login name as DOMAIN\username or username@domain.

To configure the captive portal, follow these steps:

Name

Description

Step 1. Create an authorization method, e.g., Active Directory domain-based authorization.

In the NGFW console, go to the Users and devices ➜ Auth servers section, click Add, and create an authorization server.

Step 2. Create an authentication profile with the desired authorization methods.

In the NGFW console, go to the Users and devices ➜ Auth profiles section, click Add, and create an authorization profile using the authorization method added earlier.

Step 3. Create a captive profile with the desired authentication profile.

In the NGFW console, go to the Users and devices ➜ Captive profiles section, click Add, and create a captive profile using the authorization profile added earlier.

Step 4. Create a captive portal rule.

A captive portal rule determines the type of traffic to which the user authentication methods specified in the captive profile should be applied. In the NGFW console, go to the Users and devices ➜ Captive portal section, click Add, and create a captive portal rule.

Step 5. Configure DNS for the auth.captive and logout.captive domains.

The internal auth.captive and logout.captive domain names are used by NGFW for user authorization. If the clients use NGFW as the DNS server, you do not need to do anything. Otherwise, you need to specify the IP address of the NGFW interface connected to the client network as the IP address for these domains. An alternative solution is to configure the Captive portal auth domain and Captive portal logout domain settings. For more details on these settings, see the section General Settings.

You can find an in-depth discussion of how to add authorization methods in the previous chapters. Let us now consider the creation of a captive profile and captive portal rules in more detail.

To create a captive profile, go to the Captive profiles section, click Add, and provide the desired settings:

Name

Description

Name

Captive profile name.

Description

Captive profile description.

Auth page template

Select a template for the auth page. You can create auth page templates in the Libraries ➜ Response pages section. If you need to configure user self-registration with SMS or email verification, select the corresponding template type (Captive portal: SMS auth/ Captive portal: Email auth).

Authentication mode

The method that NGFW will use to remember this user. There are two options:

  • Use IP address. Having successfully authorized the user at the captive portal, NGFW saves their IP address, and all subsequent connections from that IP address will be associated with this user. This method allows identification of data transmitted using any protocol of the TCP/IP family but will not work correctly if there is a NAT-connection between the users and NGFW.

    This is the recommended value set by default.

  • Use cookie. After a user successfully authenticates through the Captive portal, NGFW adds a cookie to the user's browser to identify subsequent connections by that user. This method allows authorization of users who are behind a NAT device but only for the HTTP(S) protocol and only in the same browser that was used for Captive portal authorization. Moreover, to authorize the user's HTTPS sessions, NGFW will decrypt all HTTPS connections on a mandatory basis. For firewall rules, a user authenticated using a cookie will always be classified as Unknown.

Auth profile

The authorization profile created earlier that defines the authentication methods to use.

Authentication mode

It is possible to authenticate using login and password via RADIUS server (AAA) or certificates (PKI).

User certificate profile

When PKI-based authentication is used, specify a pre-configured user certificate profile here.

Redirect URL

URL to redirect the user to after successful authentication using the Captive portal. If not specified, the user is redirected to the URL they requested.

Allow browsers to keep auth

Enables storing of the authorization in the browser for the specified time in hours. To store the authorization information, cookies are used.

Show AD/LDAP domain selector on Captive portal auth page

If enabled, this parameter allows the user to select the domain name from a list on the auth page if the Active Directory authentication method is used. If this parameter is not enabled, the user must explicitly specify the domain as DOMAIN\username or username@domain.

Protect with CAPTCHA

If this option is enabled, the user will be prompted to enter a code shown to them on the captive portal's auth page. This is recommended to protect against bots that guess user passwords.

HTTPS for auth page

Use HTTPS for displaying the captive portal's auth page to users. A properly configured captive portal SSL certificate is required. For more details on certificates, see the Certificate Management section.

To set up user self-registration with password verification using SMS or email, you need to configure settings on the Guest users registration tab. Remember to use the appropriate template type in this case (Captive portal: SMS auth/ Captive portal: Email auth).

Name

Description

Notification profile

The notification profile that will be used for sending information on the newly created user and their password. Two types of notification are possible, SMS and email. For more details on creating a notification profile, see the Notification Profiles chapter.

From

The person or entity in whose name notifications will be sent.

Notification subject

The subject of notifications (only for email notifications).

Notification body

The body of the notification message. In the message body, you can use special variables named {login} and {password} that will be replaced with the username and password, respectively.

Expiration date and time

The date and time when the guest account will be disabled.

Guest user TTL

The length of time from the guest user's first login after which their user account will be disabled.

Password length

Sets the password length for a guest user.

Password complexity

Sets the password complexity for a guest user. The available options are:

  • Numeric

  • Alphanumeric

  • Alphanumeric+special.

Groups

The groups to which the created guest users will be added. For more details on guest user groups, see the Guest Portal chapter.

To create a captive portal rule, go to the Captive portal section, click Add, and provide the desired settings:

Name

Description

Name

The name of the captive portal rule.

Description

A description of the captive portal rule.

Captive profile

Select a captive profile created earlier. An option is available called Skip captive portal page which, if enabled, waives the authentication requirement.

Enable logging

If this is enabled, instances of the rule being triggered will be recorded in the corresponding statistics log.

Source

The source addresses. You can use a specific zone, such as the LAN zone, or an IP address range as the source. Country IP addresses (GeoIP) can also be used.

Important! The maximum number of GeoIPs that can be specified is limited to 15.

Important! The traffic processing logic is as follows:

  • The conditions are combined using Boolean OR, if several IP address and/or domain lists are specified.

  • The conditions are combined using Boolean AND, if GeoIPs and IP address and/or domain lists are specified.

Destination

The destination addresses. You can use a specific zone, such as the WAN zone, or an IP address range as the destination. Country IP addresses (GeoIP) can also be used.

Important! The maximum number of GeoIPs that can be specified is limited to 15.

Important! The traffic processing logic is as follows:

  • The conditions are combined using Boolean OR, if several IP address and/or domain lists are specified.

  • The conditions are combined using Boolean AND, if GeoIPs and IP address and/or domain lists are specified.

Categories

The URL filtering categories to which the rule will be applied. You need to have the appropriate license for URL filtering.

URL

The URL lists to which the rule will be applied.

Time

The time when this rule will be active.

Usage

The trigger statistics for the rule: the total trigger count and the time of the first and last trigger.

To reset the trigger count, select the rules in the list and click Reset hit counts.

History

The time the rule was created and last changed as well as the related event log entries, such as rule added, rule updated, rule list position changed etc.

By creating several captive portal rules, you can configure different user identification policies for different zones, URL categories, and time.

Note The conditions specified in the rule's tabs are combined with a Boolean AND, i.e., all conditions must be met to trigger the rule. If you need to use the OR logic instead, this can be achieved by creating several rules.

Note The rules are applied in the order they are listed in the console. You can reorder the rules using the corresponding buttons.

Note When there are multiple matching rules, only the first triggered rule is applied.

To change the user after logging in to the system or to log out, go to URL http://logout.captive and click Logout.


Terminal Server Users

A terminal server is used to provide remote access to a desktop or console for users. Generally, one terminal server provides service to multiple users, sometimes even dozens or hundreds of users. Identifying terminal server users is a problem because all server users have the same IP address, and NGFW cannot correctly identify the network connections of the individual users. As a solution to this problem, use of a dedicated terminal server agent is offered. Each user is allocated a port range that is used for their connection, i.e., the original ports are substituted with the ports from the range allocated to the user.

The terminal server agent must be installed on all terminal servers that need user identification. The agent is a service that transmits information to UserGate NGFW about the users of the terminal server and their network connections. Due to the way TCP/IP works, a terminal server agent can only identify user traffic that utilizes the TCP and UDP protocols. Protocols other than TCP/UDP, such as ICMP, do not allow identification.

For correct user identification when Active Directory authorization is used on the terminal servers, an active Active Directory connector server is required.

To start using terminal server user authentication, follow these steps:

Name

Description

Step 1. Allow the Authentication agent service in the desired zone.

In the Network ➜ Zones section, allow the Authentication agent service for the zone on the terminal servers' side.

Step 2. Set a password for terminal server agents.

In the NGFW console, go to the UserGate ➜ General settings ➜ Modules section, click the Configure button next to the Password for terminal server agent entry, and set a password for terminal server agents.

Step 3. Install the terminal server agent.

Install the terminal server agent on all servers that require user identification. During the installation, specify the NGFW IP address and the password set at the previous step.

Step 4. Add the desired servers in the NGFW console.

In the Users and devices ➜ Terminal servers section, add the terminal server agents, specifying the host name and address. After receiving the data from the host specified in the settings, provided that the password set at Step 2 is correct, user authentication will be enabled automatically.

On a NGFW version update, the terminal server agents that were displayed earlier in the web console will continue working.

UserGate will now receive user information.

The terminal server agent enables not only domain users to be authenticated but also local users of a terminal server by adding the following parameter to its configuration file (%ALLUSERSPROFILE%\Entensys\Terminal Server Agent\tsagent.cfg):

LocalDomain = 1

After editing the configuration file, make sure to restart the terminal agent service.

In addition, these users need to be added to NGFW as local users. For details on adding users, see the Users section. When adding a user, specify the Login in the format: «computer name_username», without a password.

Note Only letters, numbers, and the underscore character are allowed in the computer name; hyphens are prohibited.

You can change the settings of a terminal server by editing the configuration file of the terminal server authorization agent. After making the changes, make sure to restart the authentication agent.

The settings that can be configured in the tsagent.cfg file are listed below:

  • TimerUpdate: the time interval in seconds between updates.

  • MaxLogSize: the maximum size of the service log in MB.

  • SharedKey: the password for connecting the agent.

  • SystemAccounts: can take values of 0 or 1. SystemAccounts=1 enables transmission of information about the connections of the system accounts (system, local service, network service) and the connection ports they use to NGFW.

  • FQDN: can take values of 0 or 1. FQDN=1 indicates that a FQDN (Fully Qualified Domain Name) is used, e.g., "example.com" as opposed to "example".

  • ServerPort: the port number on NGFW that accepts the connection from the authorization agent. By default, UDP port 1813 is used.

  • ServerAddress: the IP address of the UserGate device that accepts the connection from the authorization agent.

  • UserCount: the maximum number of users to create.

  • BlockDNS: can take values of 0 or 1. With BlockDNS=1 the source port is substituted with a free port from the user-allocated port range when sending DNS requests (UDP:53); with BlockDNS=0, DNS traffic is sent without port substitution.

  • BlockUDP: can take values of 0 or 1. With BlockUDP=1, the source port is substituted with a free port from the user-allocated port range when sending UDP traffic; with BlockUDP=0, the traffic is sent without port substitution.

  • ExcludeIP: if multiple IP addresses are configured on the terminal server, they will all be used for user authentication. The ExcludeIP parameter allows restriction of users' Internet access from certain IP addresses used by the terminal server.

    • IP addresses in the x.x.x.x format and/or subnet addresses in the x.x.x.x/n format are specified separated by semicolons (for example, ExcludeIP=x.x.x.x/n; x.x.x.x ).

    • Spaces are allowed between addresses in the list, they are ignored (for example, ExcludeIP=x.x.x.x/n; x.x.x.x;y.y.y.y ).

    • If there are spelling errors in the addresses in the line, they will be reflected in the logs when the agent starts. Only correctly specified addresses will be used. The number of used addresses from the list is written to the log when the agent starts.

    • If, as a result of filtering, all addresses are excluded from the distribution, then a log entry is made (once) in the form: GetIPAddressList: IP list is blocked by ExceptIP. If a non-empty distribution is later generated, a log entry is made in the form: GetIPAddressList: IP list is not blocked by ExceptIP anymore.

  • ExcludePorts: the range of ports to be excluded from being substituted with ports from the user-allocated port range. Specified as: ExcludePorts=port1-port2.

  • NAT_IP: required when there is a NAT between the terminal server and UserGate. The terminal server's IP address is substituted with an address from the specified range. The IP addresses are specified as: NAT_IP="12.3.4-1.1.1.1;2.2.2.2-5.5.5.5".

To exclude certain addresses and/or subnets from distribution by the terminal agent, in addition to adding the ExcludeIP parameter to the tsagent.cfg configuration file, it can also be activated in the server registry as follows:

  • Added as a string parameter to the Windows registry key [HKEY_CURRENT_USER\Software\Policies\Entensys\Auth Client]. In this case, the parameter settings will only apply to this user.

  • Added as a string parameter to the Windows registry key [HKEY_LOCAL_MACHINE\Software\Policies\Entensys\Auth Client]. In this case, the parameter settings will apply to all users of this system.

The order of searching for ExcludeIP parameter settings in the system is as follows: first, the parameter is searched in the registry key [HKEY_LOCAL_MACHINE\Software\Policies\Entensys\Auth Client], then in the registry key [HKEY_CURRENT_USER\Software\Policies\Entensys\Auth Client], then in the tsagent.cfg file.


MFA (Multi-Factor Authentication) Profiles

Multifactor authentication is an identification and authentication mode where two or more different types of authentication data (factors) are used. This additional level of security provides more effective protection from unauthorized access to the account.

NGFW supports multi-factor authentication using the username and password as the first authentication factor and the following types as the second factor:

  • TOTP (Time-based One Time Password) token: a TOTP token creates a time-based single-use password, i.e., time is a parameter here. For more details on TOTP, see https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm. The token may come in the form of various devices or software installed on users' smartphones, such as Google Authenticator.

  • SMS: a one-time password sent by SMS. To receive SMS messages, each user must have their phone number entered in their local NGFW user account or Active Directory domain user account.

  • Email: a one-time password sent by email. To receive emails, each user must have their email address entered in their local NGFW user account or Active Directory domain user account.

To configure multi-factor authentication, follow these steps:

Name

Description

Step 1. Configure captive-portal authorization.

Multi-factor authorization works only when users are authorized using the captive portal. For more details, see the relevant section.

Step 2. Create a multi-factor authorization profile.

In the Users and devices ➜ MFA profiles section of the console, create a multifactor authorization profile with the desired second-factor delivery settings. Three delivery types are available:

  • MFA by TOTP: deliver the second authorization factor using TOTP tokens

  • MFA by SMS: deliver the second authorization factor using SMS

  • MFA by email: deliver the second authorization factor using email.

For MFA by TOTP, provide these settings:

Name

Description

Name

The name of the MFA profile.

Description

A description of the MFA profile.

TOTP initialization

To receive TOTP tokens, you need to initialize the client device or software by entering a unique key into the device. The TOTP initialization code can be communicated by:

  • Showing it on the captive portal page after first successful login. To do this, select Show key on captive portal page.

  • Sending it by SMS. To receive SMS messages, each user must have their phone number entered in their local NGFW user account or Active Directory domain user account. This option requires selecting an appropriate SMS sending profile (SMPP profile) created earlier.

  • Sending it by email. To receive emails, each user must have their email address entered in their local NGFW user account or Active Directory domain user account. This option requires selecting an appropriate email sending profile (SMTP profile) created earlier.

Show QR code

Show a QR code on the captive portal page or in the email to facilitate TOTP device or software configuration.

If the user has lost the token, the administrator can trigger a mandatory re-initialization of the TOTP token If the user has lost the token, the administrator can trigger a mandatory re-initialization of the TOTP token Для этого ему необходимо выбрать данного пользователя в списке пользователей (Пользователи и устройства ➜ Пользователи) и выбрать действие Сбросить ключ TOTP. On the next login attempt, the user will be asked to re-initialize their token.

For MFA by SMS, provide these settings:

Name

Description

Name

The name of the MFA profile.

Description

A description of the MFA profile.

Auth delivery profile

The SMPP profile that will be used to send passwords by SMS. For more details on configuring profiles for sending SMS messages, see the Notification Profiles section.

From

The person or entity in whose name notifications will be sent.

Body

The body of the notification message. In the message body, you can use a special variable named {2fa_auth_code} that will be replaced by the one-time password.

Auth code lifetime

The validity period of the one-time password.

For MFA by email, provide these settings:

Name

Description

Name

The name of the MFA profile.

Description

A description of the MFA profile.

Auth delivery profile

The SMTP profile that will be used to send passwords by email. For more details on configuring profiles for sending email messages, see the Notification Profiles section.

From

The person or entity in whose name notifications will be sent.

Subject

Notification subject.

Body

The body of the notification message. In the message body, you can use a special variable named {2fa_auth_code} that will be replaced by the one-time password.

Auth code lifetime

The validity period of the one-time password.


UserID Agent

Description

The UserID agent is designed to perform transparent authentication on selected NGFW devices. It uses Microsoft Active Directory logs (via the WMI protocol) and Syslog (via the standardized syslog protocol RFC 3164, RFC 5424, RFC 6587) as the authentication data source.

How it works

Data for transparent authorization is taken from ActiveDirectory (AD) and/or Syslog logs. With Active Directory, a UserID agent makes requests to AD servers using WMI protocol, whereas with Syslog, the agent listens to the Syslog port (tcp\514 by default) and collects information sent in by Syslog servers. Next, the information is filtered by input/output events and entered into the Database.

The UserID agent makes periodical queries to the database to search for user logon/logoff events. The search is performed only on the records obtained through UserID sources, i.e. other records (obtained through WMI sensors, Endpoints, Log collector) are ignored. Based on the obtained data, it searches for the user in the user catalogs of the log source. If the user is found, the user's authorization data is sent to all NGFW devices specified in the Source redistribution profile, and the user is logged in to NGFW. Thus, the user is authorized on all the specified devices. If the user logs out, the situation is similar (except for WMI Connector, where user logout data is not processed at the moment). Logon/logoff/error information is stored in the UserID log.

Note Events received from the sources are displayed in the UserID logs on the "Logs and reports" tab.

Settings

In general, to configure collecting information from sources, you follow these steps:

Name

Description

Step 1. Configure audit on AD and Syslog servers

You may need to enable audit on AD servers for the following security event categories:
* Audit LogOn
* Audit LogOff
* Audit Kerberos Authentication Service
* Audit Group Membership

On syslog servers, configure log upload to the IP address of UserID Log collector.

Step 2. Create a UserID agent

To do that, go to Settings ➜ Users and devices ➜ UserID agent, click Add, and select the desired agent type.

Step 3. Configure the UserID agent settings

To do it, click Configure agent button under Users and devices ➜ UserID agent.

Step 4. Configure the event source.

You can use Microsoft Active Directory or Syslog as sources.

When configuring the agent, you must fill in the following fields:

Name

Description

General tab

General agent settings

Polling interval (sec.)

Active Directory servers polling interval. The default value is 120 seconds.

Session expiration time (sec.)

The period of time after which the user's session will be forcibly terminated. The default value is 2700 seconds (45 minutes).

Syslog Monitoring Interval (sec.)

Database poll period to look for user session start/end events in the syslog sources.

Syslog server settings tab

This tab is used to configure a Syslog collection agent.

Protocol

The underlying protocol for collecting logs using the Syslog protocol:

  • TCP

  • UUCP subsystem

To select a protocol, set the Enabled checkbox in the corresponding section.

Port

The port number used to collect Syslog events. The default port is 514.

Max session number

The maximum allowed number of concurrent devices connected for message sending.

Secure connection

Enable or disable data flow encryption. This is part of Syslog server configuration when the TCP protocol is used.

For more details on using TLS with Syslog, refer to the relevant documentation.

CA certificate file

The certification authority (CA) certificate used to establish a secure connection. This is part of Syslog server configuration when the TCP protocol is used.

Certificate file

A user-created, CA-signed certificate that needs to be specified when configuring a secure connection. This is part of Syslog server configuration when the TCP protocol is used.

Ignore network list tab

Lists of IP addresses the events from which should be ignored by the UserID agent. A record about the ignored source appears in the UserID log.

You can create the list in the Libraries ➜ IP addresses or when configuring the agent (Create and add new object button). For more details about how to create and configure IP address lists, see IP addresses.

This setting is global and applies to all sources.

Ignore user list tab

Names of users the events from which should be ignored by the UserID agent. The search is based on the Common Name (CN) of the AD user.

This setting is global and applies to all sources. A record about the ignored user appears in the UserID log.

Important! When specifying a name, you can use the asterisk (*), but only at the end of a string.
Note When NGFW connects to the Log Analyzer, UserID agents configured on both devices can operate simultaneously. The device agents will run independently of each other. UserID agent log events received by NGFW, as well as other log events, will be sent to LogAn.

Microsoft Active Directory

If Microsoft Active Directory is used as the source of information, you need:

Name

Description

Step 1. Configure the UserID agent settings for monitor Microsoft AD.

The UserID agent parameters were discussed earlier.

Step 2. Configure the event source.

Configure Microsoft Active Directory as the source. See below for more information on the source settings.

When using AD servers as event sources, NGFW performs WMI queries to search for successful logon events (event ID 4624), Kerberos events (event numbers: 4768, 4769, 4770) and group membership events (event ID 4627). The querying frequency is defined in the UserID agent settings (Polling interval). The events are displayed on the Logs and reports tab under Logs ➜ UserID agent ➜ Windows Active Directory log.
When adding an event source of Microsoft Active Directory type, you need to specify the following:

Name

Description

Enabled

Enable/disable receiving logs from the source.

Name

The source name.

Description

An optional description of the source.

Server address

Microsoft Active Directory address.

Protocol

AD access protocol (WMI).

Name

The username for connecting to AD.

Password

The user's password for connecting to AD.

Auth profile

The authentication profile used to look up users found in AD logs.

For more details on profiles, see the section Authentication Profiles.

Syslog

Note For the UserID log collector to work properly, you must configure the Syslog server to send logs to the UserID agent address. For more details, see the Syslog documentation.

To configure the event source, follow these steps:

Name

Description

Step 1. Allow collecting information from remote devices using the Syslog protocol.

Under Network ➜ Zones, enable the UserID syslog collectorservice for the zone in which the Syslog servers are located.

Step 2. Configure the UserID agent settings to monitor the Syslog server.

The UserID agent parameters were discussed earlier.

Step 3. Configure the event source.

Configure the Syslog server as the source. See below for more information on the source settings.

When adding a source of Syslog type, you need to specify the following:

Name

Description

Enabled

Enable/disable receiving logs from the source.

Name

The source name.

Description

The source description.

Server address

The host address from which NGFW will receive syslog events.

Default domain

The name of the domain used to search for users found in syslog logs.

Timezone

The time zone set on the source.

Auth profile

The authentication profile used to look up users found in Syslog logs.

Filters

Filters to find the necessary log entries.

You can create and configure filters under Libraries ➜ UserID agent Syslog filters of the agent. For more details, see UserID agent Syslog filters.

The found events are displayed on the Logs and reports tab, under Logs ➜ User-ID agent ➜ Syslog.


RADIUS Accounting

NGFW can transparently authenticate users who have already authenticated on an external RADIUS server. NGFW does not communicate with the RADIUS server; it only monitors the RADIUS accounting information redirected from the RADIUS client. The RADIUS accounting information includes the username and IP address. To configure this functionality, follow these steps:

Name

Description

Step 1. Create a user in NGFW.

Create the desired local users in NGFW. See the section Users.

Step 2. Allow the Authorization agent service in the desired zone.

In the Network ➜ Zones section, select the zone containing the interface to which RADIUS accounting information is to be sent. Allow the Authorization agent service.

Step 3. Set a password for terminal server agents.

In the NGFW console, go to the UserGate ➜ General settings ➜ Modules section, click the Configure button next to the Password for terminal service agent entry, and set a password for terminal service agent. This password will be used as the RADIUS secret at the time of configuring the RADIUS server.

Step 4. Add the RADIUS accounting source in the NGFW web console.

In the Users and devices ➜ Terminal servers section, add the RADIUS accounting information source, specifying the host name and IP address.

Step 5. Configure RADIUS accounting.

Configure the sending of RADIUS accounting information to NGFW, specifying the UserGate IP address as the server address and UDP 1813 as the port. Specify the terminal server agent password set at Step 3 as the RADIUS secret.

The username should be sent in the RADIUS User-Name attribute (type=1), user's IP address in the RADIUS Framed-IP-Address attribute (type=8), and RADIUS server IP address in the RADIUS NAS_IP_Address (attribute type=4).

For more details on configuring a RADIUS server, see the documentation for your RADIUS server and client.

Important! The RADIUS accounting information update period should not exceed 120 seconds.

Configured that way, NGFW will map the username to the user's IP address received from the RADIUS accounting server. Depending on the information being transmitted, NGFW will behave as follows:

Name

Description

The RADIUS server sent a username that does not exist in NGFW.

The Accounting-Request will be responded to with an Accounting-Reject. The user data will not change.

The RADIUS server sent an existing username and specified Acct-Status-Type = Start or Interim-Update.

The IP address sent from RADIUS will be assigned to this user. The username will start appearing in logs for this IP address. The system will start applying user rules to the traffic that uses this IP address. If this user already has an IP address different from that sent from RADIUS, two and more IP addresses will be assigned to the user.

If this IP address is already assigned to the user, nothing happens.

If this IP address is assigned to another user, it will be removed from that user and assigned to the user specified in the request.

The RADIUS server sent an existing username and specified Acct-Status-Type = Stop.

The IP address sent from RADIUS will be removed from this user. The username will stop appearing in logs for this IP address. The system will stop applying user rules to the traffic that uses this IP address.


Windows Authentication Agent

For Windows users within an Active Directory domain, there is one more authentication method available: using a dedicated authentication agent. The agent is a service that sends user information, including the username and IP address, to the NGFW server. This allows NGFW to uniquely identify all network connections of this user without having to use other authentication methods. To start working with user identification using the authorization agent, follow these steps:

Name

Description

Step 1. Allow the Authentication agent service in the desired zone.

In the Network ➜ Zones section, allow the Authentication agent service for the zone where the users are located.

Step 2. Set a password for terminal server agents.

In the NGFW console, go to the UserGate ➜ General settings ➜ Modules section, click the Configure button next to the Password for terminal server agent entry, and set a password for terminal server agents.

Step 3. Install the authentication agent.

Install the authentication agent on all computers that require user identification.

Important! The authorization agent is compatible with all Windows versions except Windows XP.

The authentication agent is supplied with an administrative template for distribution via Active Directory policies. The administrator can use this template to deploy a correctly configured agent to a large number of user computers. Using the administrative template, the administrator can specify the IP address and port of UserGate NGFW as well as the password set at the previous step. For more details on deploying software using Active Directory policies, see the Microsoft documentation.

You can also install the agent without using Group Policies. To do this, you need to install the agent from the installer and specify the necessary parameters for connecting to UserGate NGFW in the following registry keys:

[HKEY_CURRENT_USER\Software\Policies\Entensys\Auth Client]

"ServerIP"=""

"ServerPort"="1813"

"SharedKey"=""

NGFW will now receive user information. You can use user names as shown in Active Directory in your security policies; for that, you will need a configured LDAP connector. Absent a configured connector, you can use the Known and Unknown users.

Note The "ServerIP" destination address in the agent settings must match the address of the interface to which the agent's requests are received.

The installed authentication agent sends information about all IP addresses assigned to the device interfaces. In some scenarios, you may need to exclude certain IP addresses from this information by specifying a network or range in the agent settings.

You can exclude the authentication agent from sending certain addresses and/or subnets using the ExcludeIP parameter. The ExcludeIP parameter can have the following settings:

  • IP addresses in the x.x.x.x format and/or subnet addresses in the x.x.x.x/n format are specified separated by semicolons (for example, ExcludeIP=x.x.x.x/n; x.x.x.x).

  • Spaces are allowed between addresses in the list, they are ignored (for example, ExcludeIP=x.x.x.x/n; x.x.x.x;y.y.y.y).

  • If there are spelling errors in the addresses in the line, they will be reflected in the logs when the agent starts. Only correctly specified addresses will be used. The number of used addresses from the list is written to the log when the agent starts.

  • If, as a result of filtering, all addresses are excluded from the distribution, then a log entry is made (once) in the form: GetIPAddressList: IP list is blocked by ExceptIP. If a non-empty distribution is later generated, a log entry is made in the form: GetIPAddressList: IP list is not blocked by ExceptIP anymore.

The ExcludeIP parameter can be enabled on the system in several ways:

  • Added to the agent configuration file tsagent.cfg, which is created in the section: \users\<username>..ApplicationData\Entensys. After making changes, the authentication agent must be restarted. In this case, the parameter settings will only apply to the user under whose account the file was created.

  • Added as a string parameter to the Windows registry key [HKEY_CURRENT_USER\Software\Policies\Entensys\Auth Client]. In this case, the parameter settings will only apply to this user.

  • Added as a string parameter to the Windows registry key [HKEY_LOCAL_MACHINE\Software\Policies\Entensys\Auth Client]. In this case, the parameter settings will apply to all users of this system.

The order of searching for ExcludeIP parameter settings in the system is as follows: first, the parameter is searched in the registry key [HKEY_LOCAL_MACHINE\Software\Policies\Entensys\Auth Client], then in the registry key [HKEY_CURRENT_USER\Software\Policies\Entensys\Auth Client], then in the tsagent.cfg file.


Windows Proxy Agent

For Windows users, you can provide Internet access via an explicitly set proxy to programs that do not support working through a proxy. Sometimes there is also a need to provide Internet access to such programs when NGFW is not set as the default Internet gateway for user computers. In these cases, you can use a proxy agent that forwards all TCP requests not destined for local addresses to NGFW, which functions as a proxy for them.

Note The proxy agent does not authorize the user with NGFW. Therefore, if authorization is necessary, you will need to configure one of the user authorization methods, for example, install the Windows authorization agent.

The proxy agent can be installed manually or using Active Directory policies.

Note The proxy agent is compatible with all Windows versions except Windows XP.

If you are not using policies for your installation, create a text file named utmagent.cfg in the %ALLUSERSPROFILE%\Entensys\UTMAgent\ directory to configure the agent. In the configuration file, specify these settings:

ServerName=10.255.1.1

ServerHttpPort=8090

LocalNetwork=192.168.1.0/24; 192.168.0.0/24; 192.168.30.0/24;

where ServerName and ServerHttpPort are the IP address and port of the proxy server in NGFW (the default port is 8090).

Note LocalNetwork is the list of networks that do not need to be forwarded to the proxy. (The machine's interface network is excluded from being forwarded to the proxy by default).

If a program installed on the computer sends a request to an address located in the same subnet as the computer's interface, that request will not be intercepted by the proxy agent and not forwarded to the proxy address. In a similar fashion, if any program installed on the computer sends a request to an address from the subnet specified in the LocalNetwork parameter, that request will not be forwarded to the proxy by the agent.

The proxy agent service listens to the local 8080 port.

After creating or modifying the configuration file, make sure to restart the proxy agent service.

For installation via GPO, the authorization agent is supplied with an administrative template for distribution via Active Directory policies. The administrator can use this template to deploy a correctly configured agent to a large number of user computers. For more details on deploying software using Active Directory policies, see the Microsoft documentation.

All settings required for the proxy agent to work correctly are made during Group Policy configuration. During the installation, the settings are written to the registry of the user computer and have priority over the .cfg file. When the agent is uninstalled using Group Policy, the registry values are not removed and remain in this registry node:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Entensys\UTMAgent


Guest User Management

NGFW allows the creation of guest user lists. This capability can be useful for hotels, public Wi-Fi hotspots, and Internet access points where users need to be identified and given access for a limited time.

Guest users can be created in advance by the system administrator or users can be allowed to self-register in the system with SMS or email verification.

To create a guest user list as an administrator, follow these steps:

Name

Description

Step 1. (Optional) Create a guest user administrator.

  • In the Administrators section, click Add and create an administrator profile with read and write permissions set for Guest portal in the Web console permissions tab. This profile grants access to the guest user management console.

  • Create an administrator account and assign the created role to it.

For more details on creating NGFW administrators, see the relevant section of this Guide.

Step 2. Create a group to which guest users will be added as members. This group is needed to facilitate access policy management for guest users.

In the NGFW console, go to the Groups section, click Add, and create a group with the Group for guest users checkbox set. For more details on creating user groups, see the relevant section of this Guide.

Step 3. Connect to the Guest portal management console.

In the browser, go to URL https://IP_NGFW:8001/ta. Use the login and password for the device administrator or guest user administrator created at Step 1.

Step 4. Create a user list.

In the console, click Add and fill in these fields:

  • Number of users to create

  • Comment

  • Expiration date and time: the date and time when the guest account will be disabled

  • Password length: the password length for the user being created

  • Password complexity: the password complexity level for the user being created, The available options are:

  • Numeric

  • Alphanumeric

  • Alphanumeric+special

  • Guest user TTL: the length of time from the guest user's first login after which their user account will be disabled

  • Group: the group created at Step 2 to which the created guest users will be added.

The list of users thus created can be viewed in the Users list section of the guest user management console.

To enable user self-registration in the system, follow these steps:

Name

Description

Step 1. Create an SMPP notification profile (for SMS verification) or SMTP notification profile (for email verification).

In the Libraries ➜ Notification profiles section, click Add and create an SMPP or SMTP notification profile. For more details on creating notification profiles, see the Notification Profiles section.

Step 2. Create a group to which guest users will be added as members. This group is needed to facilitate access policy management for guest users.

In the NGFW console, go to the Groups section, click Add, and create a group with the Group for guest users checkbox set. For more details on creating user groups, see the relevant section of this Guide.

Step 3. Create a captive profile configured to use the notification profile for sending information about the created account.

In the Users and devices ➜ Captive profiles subsection, create a profile and configure it to use the notification profile created earlier. As the auth page template, specify Captive portal: email auth or Captive portal: SMS auth, depending on the chosen notification method. Configure the notification message, guest user group, and guest user expiration time. For more details on creating notification profiles, see the Notification Profiles section.

Step 4. Create a captive portal rule that will use the captive profile created at the previous step.

In the Users and devices ➜ Captive portal section, create a rule that will use the captive profile created earlier. For more details on creating captive portal rules, see the Captive Portal Configuration section.


UserGate Client Endpoints

The UserGate Client (UGC) software is a component of the UserGate SUMMA ecosystem, which allows the administrator to centrally manage a fleet of managed devices. Installing UGC on users' computers allows the administrator obtain device state information from them, such as CPU load, critical events that occurred on specific devices, logs for various services, logs and notifications from antimalware products, and more. The scope of information obtainable from the UGC managed devices will be constantly expanded.

With UserGate Client software, the administrator can flexibly configure security policies using firewall rules that allow filtering traffic based on source/destination addresses, users, services, URL lists and categories, applications, and content types.

The telemetry information, Windows logs and other endpoint security data is sent to the UserGate LogAn event analytics system and can be used to implement automated response to security threats.

Currently, UserGate Client can be installed on user computers running Windows 7/8/10/11. The minimum system requirements are 2GB RAM, CPU speed of at least 2GHz, and 200MB of free disk space. In the future, it is planned to expand the list of platforms for which the UserGate Client software is available.

Note An endpoint means a user computer with UserGate Client software installed.

UserGate Client + NGFW

Endpoint devices communicate with NGFW via port 4045 using the HTTPS protocol.

An endpoint device is registered after establishing a VPN connection to NGFW. At the first connection, the endpoint device checks the validity of the SSL connection certificate specified in NGFW, remembers this certificate, and uses it for subsequent verification.

Note If the certificate was changed, you need to distribute the root CA certificate to the connected endpoint devices. The certificate must be installed into the local machine's Trusted Root Certification Authorities certificate store.

After the registration, each new endpoint device is assigned a unique ID that is stored in the NGFW's database. The activity timeout for endpoint devices is 2 minutes, meaning that if NGFW receives no data from a device for 2 minutes, the device is considered inactive. After three inactivity periods have elapsed, the entry for the endpoint device is deleted from the database. On a reconnection, the device will be registered. If the endpoint device reconnects before this time elapses, its entry will be updated.

After connecting to a different VPN server, the endpoint device will be registered on the new NGFW.

HIP Checking by NGFW

Compliance checking is carried out as follows:

The endpoint device sends the following data to the NGFW:

  • the user information;

  • the system data (version, edition, netbios name);

  • the list of running processes;

  • the list of running services;

  • the list of installed software (name, vendor, version);

  • the registry keys used in HIP objects;

  • the list of system updates;

  • the startup items;

  • the information about system security (antimalware, firewall, BitLocker, etc.);

  • the information about system restore points.

The data received from the endpoint device is decrypted and forwarded for subsequent comparison with HIP profiles. The result is passed along for use in firewall rules. If the endpoint device matches all conditions of a firewall rule, that rule becomes active for the device.

Registering Endpoint Device with NGFW

The endpoint device registers with NGFW automatically after connecting to the VPN server whose data are entered on the first screen of the application GUI. UserGate Client's built-in VPN client uses the following settings to establish a VPN connection:

  • IKE mode (when IKEv1 is used): main

  • Dead Peer Detection (DPD): On idle mode.

  • Diffie-Hellman groups: Group 2 (Prime 1024), Group 14 (Prime 2048), Group 16 (Prime 4096)

  • Authentication and encryption algorithm pairs (phases 1 and 2): SHA1/AES128, SHA256/AES128, SHA384/AES128, SHA1/AES256, SHA256/AES256, SHA384/AES256, SHA1/3DES, SHA256/3DES, SHA384/3DES;

  • Key lifesize (phase 2): unlimited.

Note If the endpoint device is connected to UGМС, it will not re-register with NGFW after establishing a VPN connection.
Note A license is required to work with UserGate Client endpoints. If the appropriate license is not available, the end device will not register with the NGFW; Only the VPN connection will be established.
Note In idle mode, the neighbor's reachability check is activated when there is no IPsec traffic in the tunnel. The default setting is that DPD will be executed every 15 seconds, 5 times. After a total of one and a half minutes without DPD responses, the second party will be considered unreachable and the connection will be terminated.

To connect the endpoint:

Name

Description

Step 1. Allow connection of endpoints in the zone.

In the zone used for VPN connections, allow the Connecting endpoints service.

Step 2. Specify information to establish an SSL connection between the endpoint and NGFW.

In the UserGate ➜ Settings section, specify the certificate and profile to establish an SSL connection. When connecting, the endpoint will check the validity of the certificate. If you change the certificate on the NGFW and there are already connected endpoints, you must distribute the root certificate of the certification authority (Root CA). The certificate must be placed in the local computer store Trusted Root Certification Authorities.

TCP port 4045 is used for interaction between the endpoint and NGFW.

Step 3. Configure NGFW as a VPN server.

Configure VPN on NGFW to which the enpoint will connect. Once the VPN connection is established, the endpoint will register automatically. Security policies configured on NGFW will also be applied to the endpoints.

Important! To check compliance, the endpoint will send telemetry to NGFW every 1 minute.

The endpoint will attempt to register each time it connects to a new VPN server.

Note The VPN client built into the UserGate Client software allows connection only to servers configured for UserGate NGFW.
Note To connect via IKEv2, do not fill in the Passphrase field. When a connection is established, the application will make a request to the VPN server and, if it is configured correctly, will automatically determine the connection method (by certificate or login/password).


UserGate Client Software Installation

Description

The UserGate Client software product can be installed on computers running Windows OS 7/8/10/11. The minimum system requirements are 2GB RAM, CPU speed of at least 2GHz, and 200MB of free disk space.

The UserGate Client software is supplied as a Windows .msi or .exe setup file that can be installed manually or by using automation features.

To install the software manually, execute the setup file suitable for your system (32-bit or 64-bit). During the installation, the agent setup wizard will launch and invite you to enter the connection settings for UserGate Management Center such as the IP address of UGMC and the device code created in the Management Center.

Note To postpone the connection to UserGate Management Center, click Cancel.
Note After the installation of the UserGate Client software, the computer will be rebooted. This is required for the application to work correctly.

Automated software installation is performed using Microsoft Active Directory Group Policies. To publish the application in Active Directory, you need an .msi setup file and the administrative template UserGateClient.adm where the IP address of UGMC and the devices code created in the Management Center are specified.

When the installation is completed, UserGate Client receives the configuration assigned to it in UGMC and sends the endpoint system information to the Management Center.

The following information is available on a device:

Name

Description

General

Endpoint system information (user, computer name, IP address for Internet access, Windows OS version) and VPN connection information (connection status, VPN IP address of the device, number of bytes sent/received since the VPN connection was established, uptime).

You can also configure the following parameters:

  • Save login: stores the user login name for VPN connection after the endpoint reboot;

  • Reconnect: reconnects to the VPN server in case of a connection failure. If the connection is lost, the user will be shown the initial GUI window. If the reconnect option is active, the application will make repeated attempts to connect to the server; if the function is disabled, the initial window with server selection will be displayed. The window will be displayed in the center of the screen (if the Popup in center checkbox is active) or at its last location.

  • Popup in center: displays the initial GUI window in the center of the screen if the VPN connection is lost.

Logs

This section contains the following information:

  • Logging level: the diagnostic detail level. The options are:

    • Off: disable the diagnostics log

    • Error: log only errors

    • Warning: log only errors and warnings

    • Info: log only errors, warnings, and additional information

    • Debug: provide as much detail as possible

    The log is located at %ALLUSERSPROFILE%\UserGate\UserGate Client\var\log\usergateclient\ug_client.txt.

  • Tooltips history: notification history.

  • Export logs: download the diagnostics log (when done, the directory where the diagnostics log file was saved will open).

Network

The following information is displayed:

  • IPCONFIG: information on all network adapters and the current TCP/IP configuration.

  • ROUTING: entries from the local routing table.

  • SOCKETS: the list of active connections (port type, addresses, connection state, process ID).

To copy the information, click Copy.

Policy

Here you can view the security information for the device (status of firewall, antimalware, Windows Update, and Windows Security Center).

The status values indicated are as follows:

  • Yellow: disabled

  • Green: enabled

Advanced

This section controls content filtering (the ability of a user to disable content filtering according to policies configured on the UserGate Management Center server).

The connection data for UserGate Management Center (IP address and UGC MD device code) are specified in the file: %PROGRAMFILES%\UserGate\UserGate Client\usergateclient\bin\endpoint_gui.

UserGate Client Software Installation Recommendations

This section describes additional managed device settings that enhance the event audit capabilities of Microsoft Windows operating systems and make the audit more informative.

Note To be able to send endpoint logs to UserGate Log Analyzer in English, you must install the language pack English (US); English should be available for selection as the interface language.
Note The settings presented in this section are merely suggestions.

  1. Install the Sysmon utility that provides in-depth information on process creation, network connections, and changes in file creation times. Detailed information about the utility and the setup file can be found at this link.

  2. Add a registry key to enable querying of the Sysmon log (Microsoft-Windows-Sysmon/Operational) and sending it to the UserGate Log Analyzer server. To add the key, use the Registry Editor application or run this command:

    REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Sysmon/Operational"

  1. Enable logging for all PowerShell commands and resulting output.

    REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1

Note To quickly launch the Registry Editor application, use the Win+R keyboard shortcut, type regedit, and press Enter.

If you use Registry Editor for the task, create a variable named EnableScriptBlockLogging under the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging registry key and specify a data type of REG_DWORD and a value of 1.

Note This setting can be configured under HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, with HKEY_LOCAL_MACHINE having priority over HKEY_CURRENT_USER.

Add a registry key to enable querying of the PowerShell log (Microsoft-Windows-Powershell/Operational) and sending it to the UserGate Log Analyzer server:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Microsoft-Windows-Powershell/Operational"

  1. Enable recording of additional details of command-line process creation events in the security event log (this data will be added to the "4688: Process created" process creation event). To enable the key, use the Registry Editor application or run this command:

    REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\Audit\" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1

If you use Registry Editor for the task, create a variable named ProcessCreationIncludeCmdLine_Enabled under the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit registry key and specify a data type of REG_DWORD and a value of 1.

Note This setting is supported on devices running Windows Server 2012 R2 or later and Windows 8.1 or later OS versions.

Windows Log Events

UserGate Client provides the ability to display events in the Windows application log. Logging of the following events has been added:

  • starting and stopping the service (the UG0101 Service started, UG0102 Service stopped events);

  • connection to MC and loss of connection (the UG0201 MC connected, UG0202 MC connection lost events);

  • connection via VPN and termination of the session, including connection errors: server unavailability, incorrectly specified data (the UG0301 VPN connected, UG0302 VPN disconnected events);

  • receiving configuration from Management Center (the UG0401 MC rules propagated event).