End-users usually authenticate through a VPN client, which requests the user to authenticate as needed. See Overview to VPN Configuration (page 244) for more information about VPNs. When the VPN client is used, successful authentication opens a VPN tunnel.
End-users can alternatively open an authentication page in a web browser. The end-users can authenticate using encrypted HTTPS connections as well as plain HTTP connections. Browser-based user authentication is configured in the properties of the firewall. The IPv4 Access rules for allowing authentication connections are not included in the Default Template Policy. You must add a rule that allows this traffic in the firewall’s policy. Additionally, you must add IPv4 Access and Inspection rules to enable redirection of unauthenticated HTTP connections to the login page.
The end-users can also launch a separate Telnet authentication connection to the firewall. No special configuration is needed to use Telnet authentication.
Caution – Plain HTTP connections are unsecured and transfer user access credentials in cleartext. Use encrypted HTTPS connections to avoid loss of sensitive information.
Caution – The Telnet method transfers the username and password in cleartext and does not provide any security in addition to the initial authentication of an IP address or a connection. Use a VPN client when a higher security level is required.
Example of User Authentication on the Firewall
The example in this section illustrates a common use for User Authentication on the firewall and general steps on how the scenario is configured.
Authenticating VPN Client Users
Company A’s employees include several consultants who frequently work at customer locations, but need to remotely access Company A’s secure network. All of the company’s users are stored in StoneGate’s internal directory, and there is a separate User Group called Consultants for accounts belonging to the consultants. The administrators have set up a client-to-gateway VPN for remote access. They want to allow all users to establish a VPN tunnel to the office, but allow only users in the Consultants group to access the secure network.
1. Create a rule that establishes a VPN tunnel and allows users in the Consultants group to access the Secure Network after successful authentication:
•This rule allows any users in any directory that is defined in the system to authenticate to the VPN client if their allowed authentication methods include User Password.
•This rule allows any user whose account is stored in the internal directory to use the VPN client to establish a VPN tunnel to the office.
2. Create a rule to allow users who have established VPN tunnels to access the company’s internal networks from the DHCP-assigned IP addresses for VPN clients:
3. Transfer the policy to the firewall.
Source Destination Service Action Authentication
DHCP address range for VPN clients
HTTP SSH FTP
Consultants User Group
User Password Authentication
Source Destination Service Action Authentication
DHCP address range for VPN
clients Internal Networks ANY Allow
C HA PT E R 23
E XTERNAL U SER A UTHENTICATION
User authentication means requiring the users of services in your network to authenticate themselves before they are given access to some resources. In external user authentication, a separate server verifies the user credentials.
The following sections are included:
Overview to External User Authentication (page 194)
Configuration of External User Authentication (page 195)
Examples of External User Authentication (page 200)
Overview to External User Authentication
External user authentication means that authentication services are provided by an authentication server external to the firewall, with no replication of user information to the firewall. The external authentication server can be StoneGate’s optional Authentication Server component, or a third-party authentication server. You can use external authentication services that support the RADIUS or TACACS+ protocol, such as RSA Authentication Manager (formerly known as ACE/Server) or the IAS (Internet authentication service) of a Windows (Active Directory) server. User authentication is only supported for IPv4 traffic.
Illustration 23.1 External User Authentication Process
External user authentication proceeds as follows:
1. The user opens an authentication connection to the firewall.
2. The firewall queries the directory server to check if the user exists and which authentication method the user should use.
3. The firewall prompts the user to authenticate, and the user enters the credentials required for the authentication method.
4. The firewall relays the user credentials to the authentication sever.
5. The authentication server verifies the user credentials and responds to the firewall whether authentication succeeds or fails.
If authentication succeeds, the firewall lists the user as an authenticated user, storing both the username and authentication method.
When the user opens new connections, IPv4 Access rules that contain an authentication requirement may now match (in addition to other rules). The username and authentication method are both separately considered as matching criteria.
When the configured timeout is reached, the authentication expires and the user is removed from the firewall’s list of authenticated users. IPv4 Access rules that require authentication no longer match the user’s connections.
User Firewall 5 Directory Server
(External) Authentication Server
Configuration of External User Authentication
The illustration below shows how user authentication elements are configured.
Illustration 23.2 Configuring User Authentication
•The optional StoneGate Authentication Server component is installed as part of the Management Center installation and configured as an Authentication Server element in the system.
•External authentication servers are configured as RADIUS or TACACS+ Authentication Server elements in the system.
•RADIUS or TACACS+ Authentication Servers and the Authentication Server component can be located in any network that allows them to communicate with the firewall that has an authentication rule in its policy. The Authentication Server component must also be able to communicate with the Management Server.
•Authentication Method elements are associated with authentication servers to define the allowed authentication methods for the server, or the servers that use a particular authentication method.
•Both User and User Group elements can be used in IPv4 Access rules to define rules that only match connections from specific, successfully authenticated users.
•A specific Authentication Method definition is needed in each IPv4 Access rule especially when the Users and User Groups have several allowed Authentication Methods. Otherwise, the rules allow any defined Authentication Method that is allowed for the included users.
Directory Servers for External User Authentication
User authentication requires the creation of user accounts. You can use the same server for storing and authenticating the users, for example, when you use a Microsoft Active Directory server for both tasks. However, keep in mind that storing the user information and
authenticating the users are two separate concepts with separate options. See Directory Servers (page 181) for more information about user accounts.
To be able to define different IPv4 Access rules for different users and user groups with external authentication, you must integrate an external directory server with the SMC. Users in the Authentication Server’s directory cannot be used directly in rules. Instead, you must use the
It is also possible to use an external authentication server or the Authentication Server component without integration of an external directory server. In this configuration, it is not possible to add different IPv4 Access rules for different users and user groups, since the user information is not available to the firewall. Instead, you add the user *external* with the correct external authentication method(s) into the internal user database, and use it to define which IPv4 Access rules require authentication.
Remote Authentication Dial-in User Service (RADIUS) is a protocol for carrying authentication, authorization, and configuration information. RADIUS is a widely supported standard. For example, Microsoft IAS and RSA Authentication Manager (formerly known as ACE/Server) support the protocol and can be used for user authentication in StoneGate. The authentication methods provided by the Authentication Server component are also based on the RADIUS protocol.
RADIUS uses UDP as its transport protocol. The exchanges between the client and the RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. User passwords transferred between the client and the RADIUS server are encrypted using the MD5 message digest algorithm. The rest of the RADIUS communications are in cleartext.
Servers that provide RADIUS-based authentication methods can also be used for authenticating administrators’ Management Client logins (see the Management Center Reference Guide) and wireless client connections to wireless interfaces on firewalls (see Single Firewall Configuration (page 41)).
Additionally, the Authentication Server component can optionally collect RADIUS accounting information and provide a summary of the data. RADIUS Accounting allows you to keep track of an authenticated user’s session for billing, statistical, or network monitoring purposes. RADIUS Accounting packets contain information about when a user logs in and out of a system, and what resources the user accesses.
Terminal Access Controller Access Control System Plus (TACACS+) is a protocol used for similar purposes as RADIUS. In general, TACACS+ provides a more secure method of user
authentication than RADIUS. This is mainly because TACACS+ uses TCP as the transport protocol instead of UDP. Consequently, transport is more reliable and less sensitive to disruption at the network layer.
TACACS+ also separates authentication, authorization, and accounting services, whereas RADIUS provides a user profile defining all the user-specific parameters with the authentication.
This separation of services allows TACACS+ to use other forms of authentication, such as Kerberos, together with its own authorization.
TACACS+ uses a pre-shared key to authenticate exchanges. TACACS+ encrypts all traffic between the authentication server and the device requesting authentication. User information, such as IDs and passwords, are secured with the MD5 message digest algorithm.
Authentication methods define the authentication method used by particular authentication servers, and by particular users and user groups. The following authentication methods can be used:
•User passwords stored in internal or external LDAP databases.
•IPsec certificates and passwords (for use with IPsec VPN clients).
•Pre-shared keys (for use with some third-party VPN clients).
•Password, Mobile ID, and Mobile Text Authentication methods provided by the optional Authentication Server component.
•External authentication provided by servers that support the TACACS+ (Terminal Access Controller Access Control System Plus) protocol.
•External authentication provided by servers that support the RADIUS (Remote Authentication Dial-in User Service) protocol.
StoneGate supports many third-party Authentication Methods. You can integrate third-party authentication products with StoneGate through the RADIUS and TACACS+ protocols to provide simple password authentication, one-time passwords, or any other username/passcode-type authentication schemes.
The Authentication Server component supports the following authentication methods:
•Password is based on static password authentication. A static password is created and maintained for authenticating remote access.
•Mobile ID - Synchronized is for use with the StoneGate Mobile ID client. During
authentication, users enter their user ID and are prompted to enter a one-time password (OTP). Users enter their PIN in the Mobile ID client and the Mobile ID client software generates the OTP.
•Mobile ID - Challenge is for use with the StoneGate Mobile ID client. During authentication, users enter their user ID, and are prompted with a challenge to provide the correct response.
Users enter their PIN in the Mobile ID client, and the Mobile ID client software generates the response.
•Mobile Text is based on a combination of a PIN and one-time password (OTP) distributed by SMS to the end-user.
In Federated Authentication, user identities and authentication are managed separately from services. This allows entities that provide services to delegate the authentication process and maintenance of user accounts to another entity. Federated Authentication also allows the user to use the same credentials for authentication in multiple security domains, optionally as part of a single-sign-on (SSO) configuration.
Entities in a Federated Authentication scenario have the following roles:
•Subject: the user who requests access to an application or service.
•Identity Provider: Verifies the credentials of the user and creates a unique, signed SAML assertion that contains the information about the user and the user’s privileges. This assertion is then used to authenticate the user to the Service Provider.
The Authentication Server component can act as the Identity Provider. All Authentication Methods provided by the Authentication Server can be used to create SAML assertions for Federated Authentication.
There are three predefined Authentication Methods for use with RADIUS or TACACS+
Authentication Server elements:
•IAS Authentication is for use with an external IAS (Active Directory) server.
•Pre-Shared Key Method is for use with some third-party VPN clients.
•User Password is for simple password authentication against the internal LDAP database.
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF.