FIGURE 3-32Session Authentication wind ow — password prompt
The form of the password prompt depends on the user’s Authentication method.
Client Authentication
In This Section
Client Authentication — Overview
Client Authentication allows connections from a specific IP address after successful authentication. In contrast to User Authentication, which allows access per user, Client Authentication allows access per IP address. The user working on a client performs the authentication by providing a name and password, but it is the client that is granted access.
Client Authentication is less secure than User Authentication because it allows multiple users and connections from the authorized IP address or host. The authorization is per machine, because the supported services do not have an initial login procedure. For example, if FINGER is authorized for a client machine, then all users on the client are authorized to use FINGER, and will not be asked to supply a password during the authorization period. For this reason, Client Authentication is best enabled for single user machines.
Client Authentication — Overview page 173
Client Authentication — Deployment page 177
Client Authentication — Examples of Sign On Methods page 193
Encrypted Client Authentication page 201
Client Authentication — Security Considerations page 202
Client Authentication
The advantage of Client Authentication is that it can be used for any number of connections, for any service and the authentication is valid for any length of time. Consider the following rules:
FIGURE 3-33Example Client Authentication Rule Base
In the example rules shown in FIGURE 3-33, the first rule specifies Client
Authentication for lotus service connections whose destination is a database server. The
Source of a Client Authentication rule indicates the group of users that can authenticate, and the host or hosts from which they can authenticate. A user is authenticated according to the scheme defined in the Authentication tab of his or her
User Properties window.
Unauthorized attempts to use the lotus service on the database host will be detected by the second rule, and an alert will be issued.
Administrators can also define authorization periods and the number of permitted sessions. For example, a user working on Tower can sign on and authenticate at the start of the day and remotely access the database host throughout the day. At the end of the day, the user signs off and closes the connection with the database host.
Sign On Methods
Sign On methods specify how a user begins a Client Authentication session. Sign On methods are specified in the Client Authentication Action Properties window of a rule. There are five Sign On methods:
• Manual Sign On
The Manual Sign On method requires a user to initiate the Client Authentication session on the gateway. Manual Sign On is not transparent, because the user must first connect to the gateway. The user may initiate the Client Authentication session in one of the following ways:
• TELNET session — the user starts a TELNET session on port 259 of the gateway
• Web Browser — the user requests an HTTP connection to port 900 on the gateway using a Web browser.
Client Authentication — Overview
VPN-1/FireWall-1 also supports encrypted Client Authentication through a Web browser. This feature is available for HTTPS (HTTP encrypted by SSL) only. The user can request an HTTPS connection to a specific port on the gateway. For more information on configuring the gateway to support HTTPS, see “Encrypted Client Authentication” on page 201.
For examples using Manual Sign On, see “Manual Sign On Method” on page 193.
• Partially Automatic Sign On
Partially Automatic Sign On provides Transparent Client Authentication for
authenticated services (HTTP, TELNET, RLOGIN, and FTP). A user working with one of these services can directly request the target host. The user is then prompted and signed on through the User Authentication mechanism. If authentication is successful, access is granted from the IP address from which the user initiated the connection. The disadvantage of using this method is that it is available only for authenticated services.
For an example using Partially Automatic Sign On, see “Partially Automatic Sign On Method” on page 197.
Also see “HTTP Requests — Redirection According to Host Header” on page 202.
• Fully Automatic Sign On
Fully Automatic Sign On provides Transparent Client Authentication for all services. A user working with any service directly requests the target server. Users of
authenticated services are signed on through the User Authentication mechanism, while users working with all other services are signed-on using the VPN-1/FireWall-1 Session Authentication Agent. If authentication is successful, access is granted from the IP address that initiated the connection.
Fully Automatic Sign On is available for all services, but requires a VPN-1/FireWall-1 Session Authentication Agent on the client in order to handle non-authenticated services.
It is recommended to use Fully Automatic Sign On only if you know users have the Session Authentication Agent installed on their machines. If users do not have the Session Authentication Agent, it is recommended to use the Partially Automatic sign on method. This at least allows users of authenticated services to open a Client Authentication session on the target host without having to connect to the gateway first.
For an example using Fully Automatic Sign On, see “Fully Automatic Sign On Method” on page 198.
Client Authentication
For more information on the VPN-1/FireWall-1 Session Authentication Agent, see “Session Authentication” on page 162.
Also see “HTTP Requests — Redirection According to Host Header” on page 202.
• Agent Automatic Sign On
Agent Automatic Sign On provides Transparent Client Authentication for all services. Users are signed on through the VPN-1/FireWall-1 Session Authentication Agent. If authentication is successful, access is granted from the IP address that initiated the connection.
Agent Automatic Sign On requires that a VPN-1/FireWall-1 Session Authentication Agent be installed on each client.
If users do not have the Session Authentication Agent, it is recommended to use the Partially Automatic sign on method. This at least allows users of authenticated services to open a Client Authentication session on the target host without having to connect to the gateway first.
For an example using Agent Automatic Sign On, see “Agent Automatic Sign On Method” on page 199.
For more information on the VPN-1/FireWall-1 Session Authentication Agent, see “Session Authentication” on page 162.
• Single Sign On
Single Sign On is enabled through integration with Meta IP. This is Check Point’s address management feature which provides transparent network access. In this method, the VPN-1/FireWall-1 consults the user IP address records to determine which user is logged on at a given IP address. For more information see “Integration with Meta IP” on page 191.
For more information, see “Single Sign On — Additional Features” on page 190. For an example using Single Sign On, see “Single Sign On Method” on page 200. Partially and Fully Automatic Client Authentication rules allow users if they
authenticate successfully, but do not necessarily reject the connection if the user fails authentication. In addition, the fact that a user successfully authenticates does not necessarily mean that there is a rule that allows that user access. This is because if the service is an authenticated service, the appropriate Security Server is invoked. The authenticating Security Server first checks if the connection can be allowed by a rule which does not require authentication. For more information, see “The ‘Insufficient Information’ Problem” on page 208.