14. User Authentication

Kernun UTM applies different rules to network traffic depending on the identity of the communicating parties. A client or a server can be identified in several ways. The basic one is the IP address and the port number, which are available for any network connection. The IP-based identity is used very often, but it distinguishes between computers, not users. Sometimes it is necessary to apply different rules to different users, while each user can work on several machines and each machine can be utilized by more than one user. In such situations, we need to identify individual users, independently on the IP addresses of the computers they use. Kernun UTM provides various means of user authentication. An authenticated user name can be used as one of the conditions tested when searching for an applicable ACL.

Some application protocols allow the passing of user credentials to a proxy within the normal protocol data flow. In Kernun UTM, such type of authentication is supported by the HTTP and FTP proxies. Many other proxies are able to use out-of-band (OOB) authentication, which binds a user name to a client machine IP address. Kernun UTM also provides a special authentication mode usable for protecting access to protected HTTP servers from clients in the external network—the HTTP authentication proxy.

Examples of configuration for all variants of authentication except NTLM described in this section are summarized in the sample configuration file /usr/local/kernun/conf/samples/cml/auth.cml.

14.1. Authentication Methods

Figure 5.40. Authentication methods

Authentication methods

Kernun UTM supports several methods, described in detail in auth(7). Section ftp-proxy FTP in Figure 5.40, “Authentication methods” contains sample auth items for different authentication methods. To switch to another authentication method, simply hide the single not hidden auth item and unhide another one.

None

No user authentication is performed.

Password file

The user provides a user name and a password, which are compared to name-password pairs in a password file stored locally on Kernun UTM. The administrator must create—by utility fwpasswd(1)—a file containing valid user names with encrypted passwords (/etc/proxy-passwd in the example configuration).

RADIUS

The user name and password are verified by a RADIUS server. There are two variants: name/password (the user enters his name and the password) and challenge/response (the user enters her name, the RADIUS server generates a challenge, and the user replies by a response derived from the challenge and some secret information, e.g., using an authentication token hardware). If the radius method is chosen in an auth item, it must reference a radius-client section that defines the parameters needed to connect to a RADIUS server.

LDAP

The user name and password are verified in an LDAP database. If the ldap method is chosen in an auth item, it must reference an ldap-client-auth section that defines the parameters needed to connect to an LDAP server. If a secure connection to the LDAP server is used (the LDAP server URI begins with ldaps), the certificates to be used must be specified in the ldap-client-auth.ssl subsection.

Kerberos

The Kerberos authentication is specific to the http-proxy. If a user is authenticated in an Active Directory domain (or has a Kerberos TGT), a Web browser uses the user's Kerberos tickets and does not require any interaction with the user (name and password entry).

NTLM

The NTLM authentication is specific to the http-proxy and HTTP clients (Web browsers) running on Microsoft Windows client operating systems. If a user is authenticated in an Active Directory domain, a Web browser uses the user's credentials known by the system since the login time and does not require any interaction with the user (name and password entry). It can be combined with other authentication methods for clients that do not support NTLM.

Note

If a proxy runs in chroot, the paths in auth passwd and ldap-client-auth.ssl are interpreted in the context of the chroot directory.

14.2. Authentication in FTP Proxy

User authentication in the FTP proxy can be enabled using the auth item that specifies an authentication method other than none in session-acl. For example, a proxy with the configuration shown in Section 14.1, “Authentication Methods” will use a local password file. If authentication is enabled and the user does not provide valid credentials, the proxy terminates the session. Otherwise, it is possible to match user name or group using a user item of command-acl. There are several ways of sending authentication data to the proxy, see ftp-proxy(8). An example FTP session initiation with authentication, using a command line FTP client:

$ ftp fw.pha.tns.cz
Connected to ftp.tns.cz.
220-fw.pha.tns.cz KERNUN FTP Proxy (Version KERNUN-3_0-RELEASE) Ready.
    Target server name/address and authentication to proxy required.
    You can use loginname in form of proxy_user@server_user@server.
220 Log in with USER and PASS command.
Name (192.168.10.1:user): guest@anonymous@ftp.tns.cz
331-USER command successful.
    Proxy user: 'guest'.
    Target-server user: 'anonymous'.
    Target server: ftp.tns.cz, port: 21.
    Enter password in form proxy_user_password@server_user_password.
331 Enter password or response, please.
Password: ****@****
230-User 'guest' succesfully authenticated.
230-pha.tns.cz KERNUN FTP Proxy (Version KERNUN-3_0-RELEASE) Ready.
230-Welcome to ftp.tns.cz FTP service.
230----- proxy connected to [194.228.50.76]/ftp.tns.cz port 21 ----
    ---- proxy connected to ftp.tns.cz port 21 ----
230-Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> 

A similar, but unsuccessful session initiation (due to a wrong password):

$ ftp fw.pha.tns.cz
Connected to ftp.tns.cz.
220-fw.pha.tns.cz KERNUN FTP Proxy (Version KERNUN-3_0-RELEASE) Ready.
    Target server name/address and authentication to proxy required.
    You can use loginname in form of proxy_user@server_user@server.
220 Log in with USER and PASS command.
Name (192.168.10.1:user): guest@anonymous@ftp.tns.cz
331-USER command successful.
    Proxy user: 'guest'.
    Target-server user: 'anonymous'.
    Target server: ftp.tns.cz, port: 21.
    Enter password in form proxy_user_password@server_user_password.
331 Enter password or response, please.
Password: ****@****
421 User 'guest' not authenticated.
ftp: Login failed.
ftp>

Selected log messages related to these two FTP sessions are displayed in Figure 5.41, “Log of authentication in FTP proxy”.

Figure 5.41. Log of authentication in FTP proxy

Log of authentication in FTP proxy

14.3. Basic Authentication in HTTP Proxy

The HTTP proxy supports proxy authentication using the Basic authentication method, i.e., a name and a password entered by the user. The technical details of the authentication are described in http-proxy(8). Proxy authentication in HTTP works as follows: the first request sent by the client (browser) is unauthenticated, the proxy replies with response code 407 “Proxy Authentication Required”; upon reception of this response code, the browser displays a dialog (see Figure 5.42, “Proxy authentication dialog in a Web browser”) asking for user credentials; the browser then repeats the request with the user name and password attached.

Figure 5.42. Proxy authentication dialog in a Web browser

Proxy authentication dialog in a Web browser

Figure 5.43. User authentication configuration in the HTTP proxy

User authentication configuration in the HTTP proxy

Figure 5.43, “User authentication configuration in the HTTP proxy” contains an HTTP proxy configuration with user authentication. The authentication is enabled and the authentication method (a password file in this case) is selected by the auth item in session-acl. If a request contains user credentials, they are checked and if correct, the user name—and the list of groups the user belongs to—is remembered for matching with the user item in a request-acl. Unlike in the case of FTP proxy, a request containing invalid or no credentials is not rejected. The processing continues, but no request-acl containing a user item matches, except for the one with user none. There should be a request-acl that matches unauthenticated requests and returns the 407 response. In the example configuration, there are two request-acl sections. The first one, request-acl ALL-2, matches any successfully authenticated user. The request is processed normally, i.e., forwarded to the target server. The other, request-acl ASK-AUTH, matches if the request does not contain valid user credentials[30]. The 407 response is forced by the auth-req item. This item also sets the realm (prompt) that is usually displayed by the browser in the authentication dialog, as depicted in Figure 5.42, “Proxy authentication dialog in a Web browser”.

If we apply this sample configuration to Kernun UTM and invoke a new request in a Web browser, the log will contain messages similar to those in Figure 5.44, “Log of user authentication in the HTTP proxy”. The first request was unauthenticated. The two orange messages inform us that request-acl ASK-AUTH was selected and response 407 was returned to the browser. After the user filled in the authentication dialog, the request was repeated. The user name and password were correct, user guest was authenticated successfully, and request-acl ALL-2 was selected, as indicated by the two green messages.

Figure 5.44. Log of user authentication in the HTTP proxy

Log of user authentication in the HTTP proxy

Important

Because many Web browsers do not expect to be required to perform proxy authentication when no HTTP proxy is configured in the browser, proxy authentication may not work with a transparent proxy. It is possible in such a case that users are displayed a 407 error page instead of the authentication dialog. Use proxy user authentication with a non-transparent HTTP proxy only, unless you check that Web browsers on your client machines handle it correctly with a transparent HTTP proxy.

14.4. Kerberos Authentication in HTTP Proxy

The Kerberos authentication is an alternative to the Basic authentication described in Section 14.3, “Basic Authentication in HTTP Proxy”. It provides a single-sign-on capability for clients authenticated in an Active Directory domain or a Kerberos realm. If a user is logged in a domain, or has a valid Kerberos ticket, a Kerberos-capable Web browser can authenticate the user to the proxy automatically, without asking the user for a name and a password.

Kerberos authentication in Active Directory is supported for Microsoft Windows server and Samba 4 acting as an Active Directory domain controller. Older Samba versions (3.x) cannot be configured as an AD domain controller.

Warning

Authentication to a Samba server uses different authentication mechanism than a MS Windows Server by default. This authentication mechanism (GSS-SPNEGO) fails and may allocate all available memory. Hence, the client (Kernun http-proxy) should be configured to use GSSAPI instead. This can be done by adding file .ldaprc to the root directory and to home directories of users involved in authentication (root and kernun). The file should contain line:


SASL_MECH GSSAPI
    

Important

If an HTTP proxy uses the Kerberos authentication, it cannot be run chrooted, because it needs access to some system components that are not contained in the standard Kernun chroot environment.

An example of a Kerberos configuration is stored in the sample configuration file /usr/local/kernun/conf/samples/cml/kerberos-auth.cml. The system section contains global configuration related to the Kerberos authentication in section kerberos-auth, Figure 5.45, “Kerberos authentication — section system. Two parameters are required: the name of the Active Directory domain (or Kerberos realm) domain and the address of the domain controller (or the Kerberos KDC) ad-controller. The Kerberos authentication itself provides the name of an authenticated user to the proxy. A request-acl can be selected according to the user name or group membership. For the latter option, the proxy needs to know the list of groups the user belongs to. The list can be obtained from an LDAP server. As the Active Directory contains all the necessary information and provides LDAP interface, the Active Directory controller is usually used as the LDAP server. Obtaining group membership can be configured by unhiding the hidden item ldap and section ldap-client-auth in the sample configuration in Figure 5.45, “Kerberos authentication — section system. The URL of the LDAP server references the Active Directory controller. The proxy authenticates itself to the LDAP server by Kerberos using the machine account of the Kernun system in the Active Directory. The Kerberos authentication for LDAP is enabled by ldap-client-auth.kerberos. Alternatively, the proxy can authenticate itself using a name and a password of a user with the permission to access the Active Directory contents for reading. The user's credentials must be specified in the bindinfo item in place of ADUser, and the corresponding password in place of ldap-password. The Active Directory stores user account data in a different format than other LDAP servers used for LDAP authentication. The Active Directory format must be selected by item active-directory, which also specifies the domain name.

Important

The Active Directory domain name must be written using UPPERCASE LETTERS in the configuration.

Warning

A user's primary group name (usually Domain Users) is neither logged nor matched by request-acl.user.group.

Figure 5.45. Kerberos authentication — section system

Kerberos authentication — section system

The Kerberos configuration can be enabled in an HTTP proxy by item session-acl.kerberos-auth. Outcome of the Kerberos authentication is processed like the Basic authentication. The user name, optional list of groups, or the fact that the authentication failed, can be used as conditions in request-acl sections. There is usually one or more request ACLs that permit access to successfully authenticated users and one request ACL that denies access to unauthenticated users and asks for authentication. The sample configuration in Figure 5.46, “Kerberos authentication — section http-proxy allows access to any authenticated user (request-acl AUTH-OK). Users that are not authenticated are requested to perform authentication by request-acl AUTH-REQ.

Figure 5.46. Kerberos authentication — section http-proxy

Kerberos authentication — section http-proxy

In the Kerberos and LDAP configurations presented so far, user and group names are matched in ACLs and written to logs in a short form, without information about domains they belongs to. This may not be sufficient in a multi-domain environment, where different domains may contain users and groups with the same names. Such a multi-domain environment can comprise either domains in a single Active Directory forest, or even domains from several forests if there are explicit trusts between forests[31]. Configuration item kerberos-auth.user-match full switches to using long user name in logs and ACLs in format “user@REALM” instead of the default short format “user”. Likewise, adding value “group-match domain” to item ldap-client-auth.active-directory enables using long group names “group@domain”.

The LDAP server on each Active Directory controller returns only data from its own domain. Hence, group membership of a user must be queried in the domain which the user belongs to. The proxy is able to select the LDAP server according to the domain name of the authenticated user. To do this, there must be an ldap-client-auth section for each domain. Section kerberos-auth must contain item ldap domain, instead of naming a single ldap-client-auth section. Then the ldap-client-auth section will be selected by its Active Directory domain name (specified in item active-directory).

Information about membership of Kerberos-authenticated users in groups can be cached in order to decrease load of LDAP servers. Configuration of caching consists of adding the global section oob-auth OOB and referencing it by item http-proxy.oob-auth-srv. Cached group membership information for a user name expires after a timeout controlled by items kerberos-auth.timeout-idle (expiration after a period of inactivity) and kerberos-auth.timeout-unauth (unconditional expiration).

The Kerberos authentication requires some initialization steps before in order to start working. There are two supported methods of initialization.

Important

In order to work correctly, Kerberos authentication requires several conditions to be fulfilled:

  • The Kernun system and the Active Directory domain controller must have their system time synchronized. By default, maximum allowable clock difference is 5 min. It is possible to synchronize Kernun system's clock to the Active Directory time by configuring the domain controller as an NTP server in the Kernun configuration.

  • The Kernun system must resolve the domain name of the Active Directory domain controller to the correct IP address. The reverse resolution of this IP address must also work and yield the original domain name used for the forward resolution as the first name of the response.

14.4.1. Initialization by msktutil

The first method adds the Kernun system to the Active Directory domain by deleting its machine account if it already exists and creating a new machine account. Then it sets up the Kerberos keytab with all keys necessary for authentication and obtaining group membership information. A user account user in the Active Directory with Domain Admins rights is required for this task. The initialization process is performed by issuing shell commands on the Kernun system:

# kinit user
# ldapdelete -v -H ldap://ADC cn=COMPUTER,cn=Computers,dc=D1,dc=D2...
# msktutil -c --computer-name `hostname -s` -s HTTP/`hostname` \
-h `hostname` --server ADC --no-pac
# chown kernun /etc/krb5.keytab

where ADC is the address of the domain controller, and D1, D2, ... are components of the Active Directory domain name (e.g., for domain example.com, we use dc=example,dc=com). The computer account name COMPUTER will be the value of --computer-name with appended character '$'. If the default computer account name `hostname -s` is used, a command for automatic password renewal (msktutil --auto-update) will be added to /etc/crontab. It is possible to choose another computer account name. A non-default name must be configured in the http-proxy by setting kerberos-auth.kinit to "computername$". In this case, the machine account password renewal must be handled manually, or (better) password expiration must be turned off for the account by option --dont-expire-password of msktutil.

Important

The computer account name must be entered to the configuration with the appended character '$'.

Example: The initialization commands will be, for the domain administrator admin, the Active Directory domain EXAMPLE.COM, the domain controller ad.example.com, and the Kernun system kernun.example.com:

# kinit admin
# ldapdelete -v -H ldap://ad.example.com \
'cn=kernun$,cn=Computers,dc=example,dc=com'
# msktutil -c --computer-name `hostname -s` -s HTTP/`hostname` \
-h `hostname` --server ad.example.com --no-pac
# chown kernun /etc/krb5.keytab

If clients should access the proxy via a name different from the fully qualified host name of the Kernun system, that name must be specified in the -s argument of the msktutil command. The same name must be configured in kerberos-auth.proxy-host or session-acl.kerberos-auth.

Instead of saving the created keytab into the default location /etc/krb5.keytab, another file name can by set by adding option -k keytab_file to the msktutil command line. The custom keytab location must be configured as a shared-file referenced from kerberos-auth.keytab.

If the system is to be removed from the domain later (when Kerberos authentication is no more required or if the system will be moved to another domain), remove file /etc/krb5.keytab and delete the machine account on the Active Directory Controller.

14.4.2. Initialization by Generating a Keytab Manually

The second method of Kerberos initialization comprises generating a keytab on the Active Directory controller, transferring the keytab to the Kernun system, and configuring Kernun to use the keytab. The initialization procedure consists of several steps:

  1. Create a user account in the Active Directory. The account must be configured so that its password never expires and it must have enough rigths to read user and group information from the Active Directory (usually, membership in the Domain Users group suffices).

  2. Generate the keytab using the command line on the domain controller:

    C:\> ktpass /out KEYTAB /princ HTTP/PROXY@AD_DOMAIN
    /mapuser USER@AD_DOMAIN /pass * /crypto All
    /ptype KRB5_NT_PRINCIPAL

    where the parameters are:

    KEYTAB

    The file name for the created keytab file.

    PROXY

    The proxy name used by clients. If it it not the fully qualified host name of the Kernun system, the name must be configured in kerberos-auth.proxy-host or session-acl.kerberos-auth.

    AD_DOMAIN

    The Active Directory domain name, in upper case.

    USER

    The name of the user created in step 1. The command will request entering this user's password. Alternatively, the password may be specified on the command line by /pass PASSWD instead of /para *.

  3. Copy the keytab to the Kernun system or to the computer running Kernun GUI.

  4. Configure the keytab as a shared-file and add a reference to this shared file into kerberos-auth.keytab. The keytab shared-file should be stored in a location included in backup and upgrade, for example, /usr/local/kernun/conf.

  5. Set kerberos-auth.kinit to the proxy principal name HTTP/PROXY.

Example: The keytab creation command will be, for the Kernun user account kernun, the Active Directory domain EXAMPLE.COM, the Kernun system kernun.example.com, and the output keytab file krb5.keytab:

C:\> ktpass /out krb5.keytab /princ HTTP/kernun.example.com@EXAMPLE.COM
/mapuser kernun@EXAMPLE.COM /pass * /crypto All
/ptype KRB5_NT_PRINCIPAL

Note

Configuring a keytab as a shared file makes easy distribution of the keytab to cluster nodes.

If Kerberos authentication is no more required, remove the keytab from the Kernun system and delete the user account from the Active Directory controller.

14.5. Kerberos Authentication in Transparent HTTP Proxy

As was already mentioned, web browsers usually refuse proxy authentication on a transparent HTTP proxy. This problem can be solved by redirecting an unauthenticated transparent HTTP request to an authentication server. The server performs authentication, remembers the association of an IP address to a user name in the out-of-band authentication table, and redirects the request back to the origin server. As the Kerberos authentication is done in the background, it is invisible to the user.

An example of a Kerberos transparent proxy configuration is stored in the sample configuration file /usr/local/kernun/conf/samples/cml/kerberos-auth-transp.cml. The proxy must be configured as an OOB authentication server by adding the oob-auth global configuration section and referencing it by item http-proxy.oob-auth-srv. Kerberos and optional LDAP configuration is like in the non-transparent case, see Figure 5.45, “Kerberos authentication — section system.

The HTTP proxy configuration is shown in Figure 5.47, “Transparent Kerberos authentication — session ACLs” and Figure 5.48, “Transparent Kerberos authentication — request ACLs”. Global acl INTOK-AUTH and the corresponding session-acl INTOK-AUTH handle transparent requests to origin servers. These requests are authenticated using out-of-band authentication. Authenticated users are passed by request-acl HTTP-OK. If a user is not authenticated, the request will be redirected to the authentication server by request-acl HTTP-RDR. Redirected requests are handled by global acl HTTP-AUTH and the corresponding session-acl HTTP-AUTH. The client is asked for Kerberos authentication by request-acl AUTH-REQ. Authentication is performed by the browser without asking the user for a name or a password. Then request-acl AUTH-OK stores the IP address of the successfully authenticated user into the out-of-band table and redirects the browser to the originally requested URI. Further requests use OOB authentication and are handled without redirection to the authentication server.

Figure 5.47. Transparent Kerberos authentication — session ACLs

Transparent Kerberos authentication — session ACLs

Figure 5.48. Transparent Kerberos authentication — request ACLs

Transparent Kerberos authentication — request ACLs

Important

In Firefox, Kerberos authentication must be explicitly enabled for each server, in our example fw.pha.tns.cz. It can be done by typing a special uri about:config into the address line to show advanced settings, and then setting the server name to option network.negotiate-auth.trusted-uris.

Important

Internet Explorer, Chrome and Opera users may be prompted for a password to authenticate to the authentication server. To avoid it they must configure the browser for automatic logon. To do this

  • Go to the Internet Options dialog box, on the Security tab select Local intranet, and then click Custom Level.

  • In the Security Settings dialog box, under Logon, select Automatic logon only in Intranet zone, and then click OK.

  • In the Internet Options dialog box on the Security Settings tab with Local intranet still selected, click Sites.

  • In the Local intranet dialog box, click Advanced.

  • In the next dialog box (also titled Local intranet), type the URL of the authentication server http://fw.pha.tns.cz:8080/ in the Add this Web site to the zone box, and then click Add.

14.6. NTLM Authentication in HTTP Proxy

The NTLM authentication is an alternative to the Basic authentication described in Section 14.3, “Basic Authentication in HTTP Proxy”. It provides a single-sign-on capability for Microsoft Windows clients authenticated in an Active Directory domain. If a user is logged in a domain, an NTLM-capable Web browser can authenticate the user to the proxy automatically, without asking the user for a name and a password. The NTLM authentication can be used instead of the Basic authentication, or both authentication methods can be used together. In an NTLM-only configuration, clients incapable of the NTLM authentication cannot authenticate. In a configuration with both authentication methods, an NTLM-capable client uses NTLM and other clients use Basic.

Important

If an HTTP proxy uses the NTLM authentication, it cannot be run chrooted, because it needs access to some system components that are not contained in the standard Kernun chroot environment.

Important

The DNS domain name of the Active Directory controller must correspond to the Active Directory domain name. For example, a domain controller for the domain tns.cz should be named like ad.tns.cz.

An example of an NTLM configuration is stored in the sample configuration file /usr/local/kernun/conf/samples/cml/ntlm-auth.cml. The system section contains global configuration related to the NTLM authentication in section ntlm-auth, see Figure 5.49, “NTLM authentication — section system. Two parameters are required: the name of the Active Directory domain (domain) and the address of the domain controller (ad-controller). The NTLM authentication itself provides the name of an authenticated user to the proxy. A request-acl can be selected according to the user name or group membership. For the latter option, the proxy needs to know the list of groups the user belongs to. The list can be obtained from an LDAP server. As the Active Directory contains all the necessary information and provides LDAP interface, the Active Directory controller is usually used as the LDAP server. Obtaining group membership can be configured by unhiding the hidden item ldap and section ldap-client-auth in the sample configuration in Figure 5.49, “NTLM authentication — section system. The URL of the LDAP server references the Active Directory controller. A user with the permission to access the Active Directory contents for reading must be specified in the bindinfo item in place of ADUser, and the corresponding password in place of ldap-password. The Active Directory stores user account data in a different format than other LDAP servers used for LDAP authentication. The Active Directory format must be selected by item active-directory, which also specifies the domain name.

Figure 5.49. NTLM authentication — section system

NTLM authentication — section system

The NTLM configuration can be enabled in an HTTP proxy by item session-acl.ntlm-auth. Outcome of the NTLM authentication is processed like the Basic authentication. The user name, optional list of groups, or the fact that the authentication failed, can be used as conditions in request-acl sections. There is usually one or more request ACLs that permit access to successfully authenticated users and one request ACL that denies access to unauthenticated users and asks for authentication. The sample configuration in Figure 5.50, “NTLM authentication — section http-proxy allows access to any authenticated user (request-acl AUTH-OK). Users that are not authenticated are requested to perform authentication by request-acl AUTH-REQ.

Figure 5.50. NTLM authentication — section http-proxy

NTLM authentication — section http-proxy

Administrators often want to enable the more user-friendly NTLM authentication and to provide an alternative for clients that are not capable of the NTLM authentication. Such a configuration can be created by setting both items ntlm-auth and auth in the same session-acl, for example, by unhiding the line hidden auth passwd ... in Figure 5.50, “NTLM authentication — section http-proxy. The proxy will offer both NTLM and Basic authentication schemes. The client can choose any of them[32].

After the NTLM authentication is configured and the configuration applied to a Kernun system, it is necessary to add the Kernun system to the Active Directory domain. A user account user in the Active Directory with Domain Admins rights is required for this task. The Kernun system is added to the domain by the shell command

# net ads join -U user

The system should then be rebooted in order to initialize and start the system components that provide an interface between the proxy and the Active Directory controller[33]. If the NTLM authentication is no more required, or if the Active Directory domain or the domain controller changes, the system should be removed from the domain by the shell command

# net ads leave -U user

It can be later added to another domain by net ads join. Membership of a Kernun system in an Active Directory domain can be tested by the shell command wbinfo -t. If the system has been successfully added to a domain, we get:

# wbinfo -t; echo $?
checking the trust secret via RPC calls succeeded
0

Otherwise, the output is:

# wbinfo -t; echo $?
checking the trust secret via RPC calls failed
error code was NT_STATUS_NO_TRUST_SAM_ACCOUNT (0xc000018b)
Could not check secret
1

Results of NTLM authentication can be cached by out-of-band authentication (see also Section 14.8, “Out of Band Authentication”), in order to decrease load of Active Directory and LDAP servers. Each new client is authenticated by NTLM. The combination of the client IP address, the user name and the list of groups is remembered in the OOB session table. Following requests from the same IP address will be authenticated as the same user and groups, without contacting the AD controller and the LDAP server. Computer accounts (i.e. users whose name ends with a dollar) are not added to the OOB session table.

Configuration of NTLM caching consists of adding the global section oob-auth OOB, referencing it by item http-proxy.oob-auth-srv, and adding item auth oob OOB to each session-acl that contains item ntlm-auth. Cached user and group information for a client IP address expires after a timeout controlled by items ntlm-auth.timeout-idle (expiration after a period of inactivity) and ntlm-auth.timeout-unauth (unconditional expiration).

Tip

The preferred authentication method in Active Directory environment is Kerberos, see Section 14.4, “Kerberos Authentication in HTTP Proxy”.

14.7. HTTP Authentication Proxy

The HTTP proxy can be used to control access to a Web server in the protected network[34] from clients in the external network. A typical situation is a Web interface to a corporate mail server accessed by employees from machines in the Internet, for example from their homes. In such a case, the security policy often requires the use of sessions with limited lifetime authenticated by a strong mechanism, such as a challenge-response protocol that utilizes one-time passwords generated by hardware authentication tokens. Also, as we mentioned in Section 14.3, “Basic Authentication in HTTP Proxy”, HTTP proxy authentication does not often work if the proxy is not configured in the browser explicitly. For such situations, there is a special operation mode of the HTTP proxy, called the HTTP authentication proxy, or AProxy for short.

Figure 5.51. Configuration of the HTTP authentication proxy

Configuration of the HTTP authentication proxy

A typical AProxy configuration is displayed in Figure 5.51, “Configuration of the HTTP authentication proxy”. It is a configuration for access from clients in the Internet to the server intweb.tns.cz in the internal network. As the Internet is an untrusted network, the connections from clients are secured by TLS, which is enabled by the ssl-params APROXY-SSL section and the client-ssl item in session-acl APROXY-EXT. The internal network is considered secure, therefore plain unencrypted HTTP is used. (For detailed explanation of SSL/TLS in Kernun UTM, see Section 13, “Secure Communication Using SSL/TLS”.) The configuration section aproxy APROXY defines various parameters of the AProxy. The example contains only the auth item, which defines that the AProxy will verify user credentials against a local password file. The default maximum session time after a successful authentication is one hour. After that time, the user is logged out and must authenticate again. Also, if the session is idle—the client does not issue any request—for more than 5 minutes, the user must reauthenticate. These default timeout values can be changed by items timeout-unauth and timeout-idle of section aproxy. Further configurable AProxy parameters are described in http-proxy(5). The AProxy mode is activated by the aproxy item of a session-acl. The user name obtained during AProxy authentication can be used to select a request-acl, by matching an aproxy-user item. In the sample configuration, a client accesses the AProxy by connecting to the external IP address of Kernun UTM. If authentication succeeds, the HTTP requests from the client are passed to the internal server defined by plug-to.

Warning

An AProxy session cookie is a sensitive piece of information and should be kept secret, because an attacker could use it to steal the identity of an authenticated user. Hence, the AProxy is usually configured so that the connections between clients and the proxy are secured by SSL/TLS (see Section 13, “Secure Communication Using SSL/TLS”). It is possible to operate the AProxy using plain HTTP by enabling aproxy.insecure-cookies and not configuring client-ssl on the client side of the proxy, but it is strongly recommended not to so unless the clients are connected to Kernun UTM via a trusted network.

Figure 5.52. The user authentication dialog of the HTTP authentication proxy

The user authentication dialog of the HTTP authentication proxy

Figure 5.53. The logout confirmation message of the HTTP authentication proxy

The logout confirmation message of the HTTP authentication proxy

A user starts by entering an AProxy URL to a Web browser. The AProxy returns an authentication dialog, as displayed in Figure 5.52, “The user authentication dialog of the HTTP authentication proxy”. The user fills in their login name and password and clicks Submit. If a challenge-response authentication protocol is used[35], the user must fill in the login name only. The AProxy then displays a challenge and the user enters the response (obtained, e.g., from a hardware authentication token). If the authentication succeeds, a new session is initiated and the AProxy forwards the original HTTP request to the destination server. Further requests do not require reauthentication and are transparently passed to the server. The user must authenticate again only if the session expires because of a timeout. It is also possible to log out and terminate the session explicitly by accessing a special logout URL, as shown in Figure 5.53, “The logout confirmation message of the HTTP authentication proxy”.

The HTML authentication forms displayed by the AProxy are very simple, but their appearance is easy to modify. Form templates are stored in the /usr/local/kernun/conf/samples/error_documents directory. The template files are: aproxy-password-form.html (the form with user name and password fields), aproxy-password-form.html (the form with a response field for challenge-response authentication), and aproxy-logout.html (the logout message).

Important

The AProxy uses cookies to track sessions. The cookies are added to HTTP response messages by the proxy, but they appear to the client as coming from the server. The session cookies are then extracted by the proxy from the requests. As a cookie received from a server is never sent to other servers, it is impractical to use the AProxy for authentication of clients in the internal network accessing Web servers in the Internet.

14.8. Out of Band Authentication

Many application protocols do not support user authentication on a proxy. Even in protocols with a proxy authentication mechanism it may be undesirable to use it in some situations. Nevertheless, we may still want to perform access control and network usage monitoring for individual users. The out-of-band authentication (OOBA) provides a solution in such cases. It is based on the fact that for any network protocol, the proxy knows the IP address of the client machine. The OOBA simply binds user names with IP addresses. There is an OOBA server, which maintains a table containing pairs of user names and IP addresses. When a proxy accepts a new network connection, it sends the client IP address to the authentication server and receives the corresponding user name or the information that no user is authenticated from that IP address. As is the case with other authentication methods, the user name can be used as a condition for ACL selection.

Note

As the out-of-band authentication cannot distinguish connections from a single IP address, more than one user cannot be authenticated on a single client machine at the same time. For this reason, computer accounts (i.e. users whose name ends with a dollar) are not automatically added to the OOB session table. On the other hand, one user can be authenticated on many machines simultaneously.

Figure 5.54. Configuration of the out-of-band authentication

Configuration of the out-of-band authentication

A sample configuration of the OOB authentication is displayed in Figure 5.54, “Configuration of the out-of-band authentication”, with http-proxy HTTP-OOBA serving as the OOB authentication server, and tcp-proxy HTTPS, which allows access only to users authenticated by the OOBA. The oob-auth OOBA section defines parameters of the OOB authentication. Only the authentication method is specified in this example. See auth(5) for description of all available parameters. This session is referenced in http-proxy HTTP-OOBA by the oob-auth-srv item. The HTTP proxy is switched to the OOBA mode by adding the oob-auth item to an aproxy section and referencing this section by a session-acl. In the sample configuration, a password file is used to check user names and passwords. As the OOBA is performed in the internal network, which is assumed to be secure, plain HTTP without SSL/TLS is used, which is why insecure-cookies needs to be added to the aproxy section.

The html-form OOB authentication method is selected in the sample configuration. It authenticates users interactively in the same way as the AProxy (Section 14.7, “HTTP Authentication Proxy”). The alternative option, external (marked as hidden in the sample configuration), is to import the list of authenticated users from a server in the network. The external OOBA is fully transparent. Users do not have to do anything special, they just log in to the server that provides data to the Kernun UTM OOB authentication server. Out of the box, Kernun UTM contains the ooba-samba(1) script, which implements integration with Samba.

The tcp-proxy HTTPS proxy uses the OOB authentication and accepts authenticated users only. The OOBA is activated by setting the oob method in the auth item. The OOBA server and proxies that provide OOBA communicate via a session table file. Therefore, they must all reference the same file in the oob-auth sessions they use. If no file is specified, as in our example, a common default file will be used. The authenticated user name could be matched by a session-acl. Another way to reject unauthenticated users without creating a denying ACL for them is to add the required parameter to the auth item. It causes immediate termination of sessions initiated by unauthenticated users, even before ACL matching begins.

Figure 5.55. Login to the OOB authentication server

Login to the OOB authentication server

When the html-form OOBA method is used, a user must access the authentication page (Figure 5.52, “The user authentication dialog of the HTTP authentication proxy”) by opening the OOBA server URL in a Web browser. After entering a valid name and password, a login confirmation page is displayed, see Figure 5.55, “Login to the OOB authentication server”. It contains a link that can be used to log the user out. Like in the case of AProxy, the authentication pages displayed by the OOB authentication server can be changed by modifying template files in /usr/local/kernun/conf/samples/error_documents. There are two more OOBA authentication forms, ooba-login-confirm.html (login confirmation) and ooba-logout-confirm.html (logout confirmation), in addition to the AProxy ones, which are reused.



[30] This happens in the case of the first request or a wrong name or password entered by the user.

[31] Trusts are needed because the Kernun system authenticates itself in only one Kerberos realm, but it must be able to accept authentication from other domains and also to authenticate itself to LDAP servers in other domains.

[32] The client should choose the strongest implemented authentication scheme, in this case NTLM.

[33] Kernun uses Samba for communication related to the NTLM authentication between a proxy and the Active Directory.

[34] usually in the internal network or in the demilitarized zone

[35] implemented only for authentication method RADIUS