Figure 6.39. Authentication methods

Kernun supports several methods, described in detail in auth(7). Section ftp-proxy FTP in Figure 6.39, “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.

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 6.40, “Log of authentication in FTP proxy”.

Figure 6.40. Log of authentication in FTP 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 6.41, “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 6.41. Proxy authentication dialog in a Web browser

Figure 6.42. User authentication configuration in the HTTP proxy

Figure 6.42, “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 6.41, “Proxy authentication dialog in a Web browser”.

If we apply this sample configuration to Kernun and invoke a new request in a Web browser, the log will contain messages similar to those in Figure 6.43, “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 6.43. Log of user authentication in the 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.

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 6.44, “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 6.44, “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 6.44. 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 6.45, “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 6.45. 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 6.45, “NTLM authentication — section http-proxy”. The proxy will offer both NTLM and Basic authentication schemes. The client can choose any of them^[31].

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 Admin 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^[32]. 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.6, “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.

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).

The HTTP proxy can be used to control access to a Web server in the protected network^[33] 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 6.46. Configuration of the HTTP authentication proxy

A typical AProxy configuration is displayed in Figure 6.46, “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 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, 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. If authentication succeeds, the HTTP requests from the client are passed to the internal server defined by plug-to.

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

Figure 6.48. 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 6.47, “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^[34], 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 6.48, “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).

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.

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

A sample configuration of the OOB authentication is displayed in Figure 6.49, “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.5, “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 OOB authentication server. Out of the box, Kernun 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 6.50. Login to the OOB authentication server

When the html-form OOBA method is used, a user must access the authentication page (Figure 6.47, “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 6.50, “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.