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.