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 communications.
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.
Configuration of User Authentication 183
Default Elements
There are default elements in the system that help you start using the internal user authentication tools. The internal LDAP server’s LDAP Domain is predefined as InternalDomain.
The internal user database contains the predefined User Group Mobile VPN Users, which is used in the Default Policy Template in a rule that allows (authenticated) configuration download using legacy StoneGate VPN Clients (version 2.6 or older). To utilize the default rule with legacy VPN clients, store the user accounts in this User Group. More current StoneGate VPN Client versions do not require this type of rule.
There are also four predefined Authentication Services:
• IAS Authentication is for use with an external Active Directory server.
• IPsec Certificate is for IPsec VPN client certificate-based authentication.
• 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 or for IPsec VPN client hybrid authentication.
If you want to use the internal LDAP database for storing user information, you must add the User Group and User elements in the predefined InternalDomain LDAP Domain. If you want to use the internal tools for authentication, you must use one of the predefined Authentication Services that are configured for internal authentication.
Configuration Workflow
The following sections provide an overview of the configuration tasks related to configuring and customizing User Authentication in StoneGate. Detailed step-by-step instructions for configuring the elements and policies can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.
Task 1: Create an External Authentication Server Element
If you want to use an external authentication server instead of using one of the authentication methods supported internally in StoneGate, you must create an Authentication Server element. The configuration of RADIUS authentication for wireless users in SOHO Firewalls is explained in SOHO Firewall Configuration, on page 55.
There are separate Authentication Server elements for RADIUS and TACACS+
compatible authentication servers. The server element is used for defining the information that StoneGate needs to contact the authentication server, such as the IP address and shared secret.
If you use store user accounts in a Microsoft Active Directory and authenticate users against the Active Directory or using IAS, you can define an Active Directory Server element instead of separate LDAP and Authentication Server elements.
In addition to the StoneGate element configuration, you must naturally configure the authentication server to allow the firewalls to use the authentication services.
184 Chapter 15: User Authentication
Task 2: Create an LDAP Server Element
If you want to use an external LDAP server, you must define the parameters for contacting the server and the LDAP object classes in the form of an LDAP Server element, unless you are using an Active Directory server and define both the
authentication and user directory parameters in the combined Active Directory server element.
If administrative Domains have been created to separate configurations, use a separate external LDAP Server in each administrative Domain to create user accounts that are specific to an administrative Domain.
Task 3: Create an Authentication Service Element
The Authentication Services for all forms of internal Authentication are already predefined in the system. Also, there is a predefined Authentication Service for IAS that is always used for authentication with a Microsoft IAS and Active Directory and represents any IAS service (note that these are not displayed as part of the element).
If you are using some other external authentication server, you must define a new Authentication Service to represent the server in user properties and Access rules.
Each Authentication Service element includes one or more Authentication Servers.
The Authentication Servers you group together in the same Authentication Service are used as alternative servers if the first contacted server does not respond. All servers must contain identical information on each authenticating user, since the user has no way to determine or predict which of the alternative servers is being contacted.
Task 4: Add an LDAP Domain
When using the internal user database, the users and user groups are always stored and managed in the default LDAP Domain InternalDomain.
If you are using an external LDAP directory for user management, you must create a new LDAP Domain. After the LDAP Domain is associated with the external LDAP server, the Management Server contacts the LDAP directory and users and user groups can then be viewed and edited through the Management Client.
One LDAP Domain can be selected as the Default LDAP Domain. This allows users belonging to that LDAP Domain to authenticate without specifying the LDAP Domain information. Users in other LDAP Domains must specify their LDAP Domain whenever they authenticate themselves.
If administrative Domains have been created to separate configurations, create a separate LDAP Domain (external user database) in each administrative Domain to create user accounts that are specific to an administrative Domain. The internal LDAP database is always in the Shared Domain, which makes its contents visible in all administrative Domains. You can either select one LDAP Domain in each
administrative Domain as the Default LDAP Domain or select one of the LDAP Domains in the Shared Domain as the Default LDAP Domain for all the administrative Domains.
Configuration of User Authentication 185
Task 5: Add Users and User Groups
To implement user authentication, you must define user accounts either in the internal database or on an external server. It is not necessary to integrate an external database with StoneGate if you are using an external authentication server and you do not have to define different access rights to different users. In that case, you can create a special User element with the name *external* in the internal user database to represent any user that authenticates using the external authentication service.
Users are created as members of a User Group. This saves time and effort as you do not have to specify all user parameters separately for each individual User. A User that is a member of a User Group can inherit, for example, the Authentication Service and account expiration time from the User Group. Each User Group must belong to an LDAP Domain.
We recommend that each user has a separate user account used by that person. You can create Users to any User Groups under either StoneGate’s internal LDAP Domain or under any external LDAP domain. Each user can belong to several User Groups within the LDAP Domain. User-specific properties can override properties defined at the User Group level.
You can import and export Users and User Groups to/from the internal user database through an LDIF file to transfer the information to/from a StoneGate LDAP database.
Task 6: Define User Authentication in Access Rules
The Access rules in a firewall policy can be configured to match only when the user is authenticated. With client-to-gateway VPNs, some form of authentication is always mandatory, but authentication can be required for non-VPN access as well. The authentication parameters are defined in the Users and Authentication cells.
Illustration 15.3 Authentication Field in the Access Rules
The user authenticates by launching a separate authentication connection using Telnet from the client to the firewall (for example, by running a script you prepare) or through the VPN client (authentication is triggered either manually or automatically).
The rules for allowing both types of authentication connections are included in the Default Template Policy as a separate rule for Telnet authentication and as part of a rule that allows VPN negotiations (authentication is done within the IKE negotiations).
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.
186 Chapter 15: User Authentication
With authorization for Client IP, the IP address of the remote system is granted access through the firewall for a specific period of time. This allows any number of
connections from the client during this period. All connections from the source IP address are authorized, so in Telnet-based authentication, multi-user systems should use the Connection option instead (see below). Client IP authorization must be used with client-to-gateway VPNs and it can be used with Telnet-based authentication.
With authorization for the Connection, access is given to one connection through the firewall from a successfully authenticated client. The user has to authenticate again for the next connection. Connection authorization can be used with Telnet-based authentication, but it cannot be used with client-to-gateway VPNs.