Legacy Authentication

This section covers how to work with legacy authentication methods.

Configuring Authentication

On the Security Gateway, you can configure authentication in one of two places:

• In the Gateway Properties window of a gateway in Authentication. In the Authentication page, you can allow access to users who authenticate with a Check Point Password, SecurID, OS Password, RADIUS server, or TACACS server. Authentication using Client Certificates from the Internal Certificate Authority is enabled by default in addition to the selected method.
• Some blades have their own authentication settings. Configure this in the Gateway Properties window of a gateway under <name of the blade> > Authentication. For example, configure the authentication method for IPsec VPN clients in Gateway Properties > IPsec VPN > Authentication. If you select an authentication method for the blade, that is the method that all users must use to authenticate to that blade. You can configure other authentication methods that users must use for different blades on different pages.

  If you do not make a selection on the Authentication page for a specific blade, the Security Gateway takes authentication settings for the blade from the main gateway Authentication page.

How the Gateway Searches for Users

If you configure authentication for a blade from the main Security Gateway Legacy Authentication page, the Security Gateway searches for users in a standard way when they try to authenticate. The gateway searches:

1. The internal users database.
2. If the specified user is not defined in this database, the gateway queries the User Directory (LDAP) servers defined in the Account Unit one at a time, and according to their priority.
3. If the information still cannot be found, the gateway uses the external users template to see if there is a match against the generic profile. This generic profile has the default attributes applied to the specified user.

If you configure an authentication method for a specific blade, the gateway searches for users according to the user groups that are used for authorization in that blade.

For example, in Mobile Access, the gateway looks at the Mobile Access policy to see which user groups are part of the policy. When the gateway tries to authenticate a user, it starts to search for users in the databases related to those user groups.

In IPsec VPN, the gateway looks at the Remote Access VPN Community to see which user groups are included. It starts to search for users in the databases related to those user groups.

A search based on the authentication scheme is faster, with better results. You can have users with the same user name in unrelated groups. The gateway will know which user is relevant for the blade based on the user groups.

Authentication Schemes

Security Gateways authenticate individual users using credentials and manages them using different authentication schemes. All of the authentication schemes require the provision of a user name and password. While some schemes involve storing the passwords on the gateway, others are stored on external servers.

The following sections describe the various authentication schemes supported by Check Point.

Check Point Password

The Security Gateway can store a static password in the local user database of each user configured in Security Management server. No additional software is required.

Operating System Password

The Security Gateway can authenticate using the user name and password that is stored on the operating system of the machine on which the Security Gateway is installed. You can also use passwords that are stored in a Windows domain. No additional software is required.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is an external authentication scheme that provides security and scalability by separating the authentication function from the access server.

Using RADIUS, the Security Gateway forwards authentication requests by remote users to the RADIUS server. The RADIUS server, which stores user account information, authenticates the users.

The RADIUS protocol uses UDP to communicate with the gateway. RADIUS servers and RADIUS server group objects are defined in SmartDashboard.

Configuring a Security Gateway to use RADIUS Authentication

To configure a Security Gateway to use RADIUS authentication:

1. In SmartDashboard, create a RADIUS Host object by selecting Manage > Network Objects > New > Node > Host.
2. Name the Host object and assign it an IP address.
3. Create a RADIUS Server object by selecting Manage > Server and OPSEC Applications > New > RADIUS, and configure the following:
   1. Name the RADIUS Server object.
   2. Associate the RADIUS Server object with the RADIUS Host object created in step 1.
   3. Assign the Service by selecting either the RADIUS on port 1645 or NEW-RADIUS on port 1812 service. (The default setting is RADIUS, however the RADIUS standards group recommends using NEW-RADIUS, because port 1645 can conflict with the datametrics service running on the same port.)
   4. Assign the same Shared Secret that you configured on the actual RADIUS server.
   5. Select either RADIUS Ver. 1.0 Compatible, which is RFC 2138 compliant, or RADIUS Ver. 2.0 Compatible, which is RFC 2865 compliant.
   6. Assign the RADIUS server's Priority if you are employing more than one RADIUS Authentication server.
   7. Click OK.
4. Right-click the gateway object and select Edit >Authentication.
5. Enable RADIUS authentication.
6. Define a user group by selecting Manage > Users & Administrators > New > User Group (for example, RADIUS_Users).
7. Enable RADIUS authentication for Security Gateway users by selecting Manage > Users and Administrators > New > User by Template > Default.
8. Enable RADIUS authentication for users without Security Gateway user accounts by creating an External User Profile. Select Manage > Users and Administrators > New > External User Profile > Match all users or Match by domain. To support more than one external authentication scheme, define your External User Profiles with the Match By Domain setting.
9. For all User Profiles and Templates, configure the following:
   1. In the General tab, type the default login name for the RADIUS server. (When configuring Match all users as an External User Profile, the name "generic*" is automatically assigned.)
   2. In the Personal tab, adjust the Expiration Date.
   3. In the Authentication tab, select RADIUS from the drop-down list.
   4. In the Groups tab, add the User Profile to the RADIUS group.
10. Verify that communication between the firewall and the RADIUS server are not defined in the Address Translation Rule Base.
11. Save, verify, and install the policy.

Granting User Access Using RADIUS Server Groups

The Security Gateway enables you to control access for authenticated RADIUS users, based on the administrator's assignment of users to RADIUS groups. These groups are used in the Security Rule Base to restrict or grant access to users to specific resources. Users are unaware of the groups to which they belong.

To use RADIUS groups, you must define a return attribute in the RADIUS user profile of the RADIUS server. This attribute is returned to the Security Gateway and contains the group name (for example, RAD_<group to which the RADIUS users belong>) to which the users belong. Although other RADIUS attributes can be used, by default the Class attribute is used (IETF RADIUS attribute number 25).

To grant access using RADIUS server groups:

1. On the Security Gateway, follow step 1 to step 4 in Configuring a Security Gateway to use RADIUS.
2. Create an External User Profile by selecting Manage > Users and Administrators > New > External User Profile > Match all users. This is the generic* user.
3. In the Authentication tab, select RADIUS as the Authentication Scheme and then select the created RADIUS server (not the node) from the drop-down list.
4. Define the required RADIUS user groups by selecting Manage > Users & Administrators > New > User Group. The name of the group must be in the format: RAD_<group to which the RADIUS users belong>. Ensure the group is empty.
5. Create the required Rule Base rules to allow access to RADIUS users.
6. Save the changes, and exit SmartDashboard.
7. Run cpstop on the Security Management server.
8. On the Security Management server, use the Graphical Database Tool (GUIdbEdit) to change the value of the add_radius_groups attribute from false to true.
9. Run cpstart on the Security Management server.
10. Install the policy.
11. On the RADIUS server, modify the RADIUS users to include a class RADIUS attribute on the users Return list that corresponds to the user group that they access.

To use a different attribute instead of the class attribute, do one of the following:

1. On the Security Gateway, use GUIdbEdit to modify the value of the firewall_properties attribute radius_groups_attr to the new RADIUS attribute.
2. On the RADIUS server, ensure that you use the same RADIUS attribute (on the users' Return list that corresponds to the Firewall user group that they access).

Associating a RADIUS Server with Security Gateway

You can associate users with the Radius authentication server in the User PropertiesAuthentication tab. You can also associate a gateway with a Radius server so that this overrides the User to Radius server association. This is performed by editing the database using the dbedit command.

To associate one or more Radius servers to a gateway:

1. Run the dbedit command as follows:

   modify network_objects <gw obj> radius_server servers:<radius obj>

2. To switch off the Radius to the Security Gateway association so that the user always authenticates to the Radius server specified in the User Properties Authentication tab, switch off another attribute in the database by running the dbedit command:

   modify users <user obj> use_fw_radius_if_exist false

SecurID

SecurID requires users to both possess a token authenticator and to supply a PIN or password. Token authenticators generate one-time passwords that are synchronized to an RSA ACE/server and may come in the form of hardware or software. Hardware tokens are key-ring or credit card-sized devices, while software tokens reside on the PC or device from which the user wants to authenticate. All tokens generate a random, one-time use access code that changes approximately every minute. When a user attempts to authenticate to a protected resource, the one-time use code must be validated by the ACE/server.

Using SecurID, the Security Gateway forwards authentication requests by remote users to the ACE/server. ACE manages the database of RSA users and their assigned hard or soft tokens. The gateway acts as an ACE/Agent 5.0 and directs all access requests to the RSA ACE/server for authentication. For additional information on agent configuration, refer to ACE/server documentation.

There are no specific parameters required for the SecurID authentication scheme.

Configuring a Security Gateway to use SecurID Authentication

To configure a Security Gateway to use SecurID:

1. Generate and copy the sdconf.rec file from the ACE/Server to:
   • /var/ace/sdconf.rec on UNIX, Linux or IPSO
   • %SystemRoot%\System32\sdconf.rec on Windows
2. In SmartDashboard, right-click the gateway object and select Edit >Authentication page.
3. Enable SecurID authentication.
4. Define a user group by selecting Manage > Users & Administrators > New > User Group (for example, SecurID_Users).
5. Enable SecurID authentication for Security Gateway users by selecting Manage > Users and Administrators > New > User by Template > Default.
6. Enable SecurID authentication for users without Security Gateway user accounts by creating an External User Profile. Select Manage > Users and Administrators > New > External User Profile > Match all users or Match by domain. If you support more than one external authentication scheme, set up your External User Profiles with the Match By Domain setting.
7. For all User Profiles and Templates, configure the following:
   1. In the General tab, enter the default login name for the ACE/Server. (When configuring Match all users as an External User Profile, the name "generic*" is automatically assigned).
   2. In the Personal tab, change the Expiration Date.
   3. In the Authentication tab, select SecurID from the drop-down list.
   4. In the Groups tab, add the User Profile to the SecurID group.
8. Verify that communication between the firewall and the ACE/Server are not NATed in the Address Translation Rule Base.
9. Save, verify, and install the policy.

TACACS

Terminal Access Controller Access Control System (TACACS) provides access control for routers, network access servers and other networked devices through one or more centralized servers.

TACACS is an external authentication scheme that provides verification services. Using TACACS, the Security Gateway forwards authentication requests by remote users to the TACACS server. The TACACS server, which stores user account information, authenticates users. The system supports physical card key devices or token cards and Kerberos secret key authentication. TACACS encrypts the user name, password, authentication services and accounting information of all authentication requests to ensure secure communication.

Configuring a Security Gateway to use TACACS+ Authentication

To configure a Security Gateway to use TACACS+:

1. In SmartDashboard, create a TACACS Host object by selecting Manage > Network Objects > New > Node > Host
2. Name the Host object and assign it an IP address.
3. Create a TACACS server by selecting Manage > Server and OPSEC Applications > New…> TACACS…, and configure the following:
   1. Name the TACACS server object.
   2. Associate the TACACS server object with the TACACS Host object created in step 1.
   3. Select the Type of TACACS you want to run. (The default is TACACS, but TACACS+ is recommended).
   4. Assign the Service. Match the TACACS service (UDP or TCP) to the Type selected in step c.
4. Right-click the gateway object and select Edit > Authentication.
5. Enable TACACS authentication.
6. Define a user group by selecting Manage > Users & Administrators > New > User Group (for example, TACACS_Users).
7. Enable TACACS authentication for Security Gateway users by selecting Manage > Users and Administrators > New > User by Template > Default.
8. Enable TACACS authentication for users without Security Gateway user accounts by creating an External User Profile. Select either Manage > Users and Administrators > New > External User Profile > Match all users or Match by domain. If more than one external authentication scheme is supported, set up your External User Profiles using the Match By Domain setting.
9. For all User Profiles and Templates, configure the following:
   1. In the General tab, enter the default login name for the TACACS Server. (When configuring Match all users as an External User Profile, the name "generic*" is automatically assigned).
   2. In the Personal tab, change the Expiration Date.
   3. In the Authentication tab, select TACACS from the drop-down list.
   4. In the Groups tab, add the User Profile to the TACACS group.
10. Verify that communication between the firewall and the TACACS server is not NATed in the Address Translation Rule Base.
11. Save, verify, and install the policy.

Undefined

The authentication scheme for a user can be defined as undefined. If a user with an undefined authentication scheme is matched to a Security Rule with some form of authentication, access is always denied.

Authentication Methods

Instead of creating a security rule that simply allows or denies connections, the firewall administrator can request that clients authenticate when they try to access specific network resources.

There are three authentication methods available: user, client and session. These methods differ in the services provided, the logon mechanism, and the overall user experience. Each method can be configured to connect and authenticate clients to the gateway before the connection is passed to the desired resource (a process known as nontransparent authentication). Alternatively, each method can be configured to connect clients directly to the target server (a process known as transparent authentication).

User Authentication

User Authentication provides authentication for Telnet, FTP, HTTP, and rlogin services. By default, User Authentication is transparent. The user does not connect directly to the gateway, but initiates a connection to the target server.

The following is a typical User Authentication method workflow:

1. The Security Gateway intercepts the communication between the client and server.
2. The Security Gateway prompts the user for a user name and password.
3. If the user successfully authenticates, the gateway passes the connection to the remote host. If incorrect credentials are presented, the user is prompted to re-enter the data. After a predefined number of unsuccessful connection attempts, the connection is dropped.
4. The remote host prompts the user for a user name and password.

Configuring User Authentication

To configure user authentication:

1. Configure authentication for required users and groups and install the user database. For detailed information, refer to Creating Users and Groups.
2. Define a user authentication access rule as follows:
   1. Right-click in the Source column, select Add object > Add legacy user access and then select the group.
   2. To restrict the location of authenticating users, select Restrict To and the host, group of hosts, network or group of networks that users can access in the Location section of the same window.
   3. In the Service field, select the services you wish to authenticate.
   4. In the Action column, select Legacy > User Auth.
3. Double-click the Action column to edit the User Authentication Action Properties.
4. If required, adjust the User Authentication session timeout from the Authentication page of the Security Gateway object.
5. Install the security policy: Policy > Install.

Importance of Rule Order in User Authentication

When defining user authentication rules for Telnet, FTP, HTTP, and RLOGIN services, if there are other non-authentication rules that use these services, ensure that the user authentication rule is located last amongst these rules.

Session Authentication

Session Authentication can be used for any service, however, a Session Authentication agent is required to retrieve a user's identity. The Session Authentication agent is normally installed on the authenticating client, whereby the person who initiates the connection to the destination host, supplies the authentication credentials. Session authentication requires an authentication procedure for each connection, however, the Session Authentication agent can also be installed on the destination machine, or on some other machine in the network, thereby allowing the user at that machine to provide the user name and password.

The following is a typical Session Authentication workflow:

1. The user initiates a connection directly to the server.
2. The Security Gateway intercepts the connection.
3. The Session Authentication agent challenges the user for authentication data and returns this information to the gateway.
4. If the authentication is successful, the Security Gateway allows the connection to pass through the gateway and continue to the target server.

Configuring Session Authentication

To configure session authentication:

1. If using the Session Authentication Agent, install and configure it for all machine desktops with Session Authentication enabled.
2. Configure the users and groups for authentication, and install the user database. Refer to Creating Users and Groups for more information.
3. From the Authentication page, edit the Check Point Gateway object that represents the gateway and enable the required authentication schemes. The gateway must support all of the user defined authentication schemes. For example, if some users must provide a Check Point password, and others RADIUS authentication, select both schemes.
4. Define a Session Authentication access rule by doing the following:
   1. Right-click in the Source column, select Add object > Add legacy user access and then the group. Do not close the window.
   2. To restrict the location of authenticating users, in the Location section of the same window, select Restrict To and the host, group of hosts, network or group of networks that users can access.
   3. In the Service field, select the services you want to authenticate.
   4. In the Action column, select Legacy > Session Auth.
5. Double-click the Action column to edit the User Authentication Action Properties.
6. If required, adjust the Failed Authentication Attempts settings for Session Authentication in the Authentication page of the Global Properties.
7. Install the security policy.

Installing and Configuring Session Authentication Agent

To install and configure the Session Authentication Agent:

1. Install the Session Authentication agent from the DVD.
   • If the Session Authentication agent is installed on the authenticating client, users who want to connect to the destination host provide the authentication credentials.
   • If Session Authentication agent is installed on the destination machine or on some other machine in the network, the user at the machine on which the Agent is installed is prompted to provide authentication credentials.
2. On Windows machines, double-click the Session Authentication agent icon in the system tray. The Session Authentication window.
3. Click Configure. The Configuration window opens and displays the Passwords tab. Specify how often the user is prompted to provide their password. One-time passwords (such as SecurID) cannot be cached.
4. Select one of the following options:
   • Every request: The user is prompted for a password each time that the Security Gateway requests authentication. Each time that the user initiates a session for which a Session Authentication Rule applies, the user is prompted for the password. No password caching occurs.
   • Once per session: The user is prompted for the password once per Session Authentication Agent session. Once the user provides the password, the Session Authentication agent caches the password indefinitely. This option cannot be used with one-time passwords. If the Session Authentication Agent session is closed and then restarted, the user must provide the password again.
   • After minutes of inactivity: Similar to the Once per session option, however, the user is prompted again for the password if there has been no authentication request over a specified time interval.
5. In the Configuration window, select the Allowed FireWall-1 tab and specify the Security Gateways for which the Session Authentication agent can provide authentication services.
6. Select one of the following options:
   • Any IP Address: The Session Authentication agent can provide authentication services for any Security Gateway.
   • IP Address: The Session Authentication agent can provide authentication services for only a Security Gateway running on a user-specified IP address (you can specify up to three IP addresses).
7. In the Configuration window, select the Options tab and specify whether to allow clear passwords and to resolve addresses.
8. Select the appropriate option and click OK.

Starting the Session Authentication Agent

To start the Session Authentication Agent:

1. From the Windows system tray, select the minimized Session Authentication Agent icon.
2. Configure the Session Authentication Agent and/or receive authentication requests from a Security Gateway.

Client Authentication

Client Authentication can authenticate any service. It enables access from a specific IP address for an unlimited number of connections. The client user performs the authentication process, but it is the client machine that is granted access. Client Authentication is less secure than user authentication because it permits access for multiple users and connections from authorized IP addresses or hosts. Authorization is performed on a per machine basis for services that do not have an initial login procedure. The advantages of Client Authentication are that it can be used for an unlimited number of connections, for any service, and is valid for any length of time.

Client Authentication works with all sign on methods. The following table shows how different sign on methods provide choice when selecting an authentication method for authenticated and other services. For sign on methods other than Manual Client Authentication, the gateway is transparent to the users and they authenticate directly to the destination host.

Client Authentication Sign On Methods

The following are the two Client Authentication sign on options:

• Standard Sign on: Enables users to access all services permitted by the rule without authenticating for each service.
• Specific Sign on: Enables users to access only the services that they specify when they authenticate, even if the rule allows more than one service. If the user wants to use another service, they must re-authenticate for that specific service.

At the end of an authentication session, the user can sign off. When a user signs off, they are disconnected from all services and the remote host.

Manual Sign On

Manual Sign On is available for any service that is specified in the Client Authentication rule. The user must first connect to the gateway and authenticate in one of the following two ways:

1. Through a Telnet session to the gateway on port 259.
2. Through an HTTP connection to the gateway on port 900 and a Web browser. The requested URL must include the gateway name and the port number, for example, http://Gateway:900.
   1. The following example shows Client Authentication using a Standard Manual Sign On method. In this example, before opening a connection to the destination host, the user fbloggs first authenticates to london, the Security Gateway.

tower 1% telnet london 259
Trying 191.23.45.67 ...
Connected to london.
Escape character is '^]'.
CheckPoint FireWall-1 Client Authentication Server running on london
Login: fbloggs
FireWall‑1 Password: ********
User authenticated by FireWall-1 auth.

Choose:
	(1) Standard Sign On
	(2) Sign Off
	(3) Specific Sign On

Enter your choice: 1

User authorized for standard services (1 rules)
Connection closed by foreign host.

1. The following example shows Client Authentication using a Specific Manual Sign On method. In this example, two services are specified: rstat and finger (each one to a different host).

tower 3% telnet london 259
Trying 191.23.45.67 ...
Connected to london.
Escape character is '^]'.
CheckPoint FireWall-1 Client Authentication Server running on london
Login: jim
FireWall‑1 Password: ********
User authenticated by Internal auth.

Choose:
	(1) Standard Sign On
	(2) Sign Off
	(3) Specific Sign On

Enter your choice: 3
Service: rstat
Host: palace
Client Authorized for service
Another one (Y/N): Y
Service: finger
Host: thames
Client Authorized for service
Another one (Y/N): n
Connection closed by foreign host.

Wait Mode

Wait mode is a Client Authentication feature for Manual Sign On when the user initiates a client authenticated connection with a Telnet session on port 259 on the gateway.

Wait mode eliminates the need to open a new Telnet session in order to sign off and withdraw client authentication privileges. In Wait mode, the initial Telnet session connection remains open so long as client authentication privileges remain valid. Client authentication privileges are withdrawn when the Telnet session is closed.

The Security Gateway keeps the Telnet session open by pinging the authenticating client. If for some reason the client machine stops running, the gateway closes the Telnet session and client authentication privileges from the connected IP address are withdrawn.

Enable Wait mode works only with client authentication rules that specify Standard Sign On. In Enable Wait mode, client authentication rules that require Specific Sign On are not applied.

Partially Automatic Sign On

Partially Automatic Sign On is available for authenticated services (Telnet, FTP, HTTP and RLOGIN) only if they are specified in the client authentication rule. If the user attempts to connect to a remote host using one of the authenticated services, they must authenticate with User Authentication. When using Partially Automatic Client Authentication, ensure that port 80 is accessible on the gateway machine.

Fully Automatic Sign On

Fully Automatic Sign On is available for any service only if the required service is specified in the client authentication rule. If the user attempts to connect to a remote host using an authenticated service (Telnet, FTP, HTTP, and RLOGIN), they must authenticate with User Authentication. If the user attempts to connect to a remote host using any other service, they must authenticate through a properly installed Session Authentication agent. When using Fully Automatic Client Authentication, ensure that port 80 is accessible on the gateway machine.

Agent Automatic Sign On

Agent Automatic Sign On is available only if the required service is specified in the Client Authentication rule, and the Session Authentication agent is properly installed.

If a user attempts to connect to a remote host using any service, they must authenticate through a Session Authentication agent.

Single Sign On

Single Sign On is available for any service only if the required service is specified in the Client Authentication rule and UserAuthority is installed.

Single Sign On is a Check Point address management feature that provides transparent network access. The Security Gateway consults the user IP address records to determine which users are logged on to any given IP address. When a connection matches a Single Sign On enabled rule, the gateway queries UserAuthority with the packet's source IP. UserAuthority returns the name of the user who is registered to the IP. If the user's name is authenticated, the packet is accepted, if not, it is dropped.

Configuring Client Authentication

To configure basic client authentication:

1. Configure the required users and groups for authentication and install the user database. Refer to Creating Users and Groups for details.
2. From the Authentication page, edit the Check Point Gateway object that represents the Security Gateway and enable the required authentication schemes. The gateway must support all of the user defined authentication schemes. For example, if some users must provide a Check Point password, and others RADIUS authentication, select both schemes.
3. Define a Client Authentication access rule as follows:
   1. Right-click in the Source column, select Add object > Add legacy user access and then the group. Do not close the window.
   2. To restrict the location of authenticating users, in the Location section of the same window, select Restrict To and the host, group of hosts, network or group of networks that users can access.
   3. In the Service field, select the services you want to authenticate.
   4. In the Action column, select Legacy > Client Auth.
4. For Partially or Fully Automatic Client Authentication, ensure that port 80 is accessible on the gateway machine.
5. Double-click in the Action column to edit the Client Authentication Action Properties. The settings for Requires Sign On and Sign On Method are described in Client Authentication.
6. Place all Client Authentication Rules above the rule that prevents direct connections to the Security Gateway (the Stealth Rule) to ensure that they have access to the Security Gateway.
7. If required, adjust the Failed Authentication Attempts settings for Client Authentication in the Authentication page of the Global Properties window.
8. Install the security policy.

Enabling Client Authentication Wait Mode

When using Manual Sign On and the user authenticates with a Telnet session to port 259 on the gateway, Wait mode eliminates the need to open a new Telnet session in order to sign off and withdraw client authentication privileges.

To enable Wait mode:

1. From the Authentication page, edit the Check Point Gateway object that represents the Security Gateway and select Enable Wait Mode for Client Authentication. In Client Authentication Wait mode, the Security Gateway monitors the Telnet connection to port 259 of the gateway by pinging the user's host.
2. Define rules to enable pinging as follows:
   • Enable the echo-request service from the Security Gateway to the user's host.
   • Enable the echo-reply service from the user's host to the Security Gateway.

Resolving Access Conflicts

When configuring users, you define those locations that they can access. However, by doing so, you disallow access to all unspecified locations, which can cause conflicts with security rules that require authentication.

For example, if a rule grants authenticated access to users from Marketing_net to Finance_net, but in the user's Location tab connections are only permitted within Marketing_net, the firewall does not know whether to allow the authentication request when the user tries to connect to Finance_net.

You can specify how to resolve this conflict by editing the Authentication Action Property of this rule. You can define this property for both the Source and Destination of the rule.

To resolve access conflicts:

1. Right-click the Action field of a rule using some form of authentication and select Edit Properties.
2. Do one of the following:
   • To apply the more restrictive access privileges specified in the rule and in the Location tab of each user's User Properties window, select Intersect with User Database.
   • To allow access according to the location specified in the rule, select Ignore User Database.

Authorizing All Standard Sign On Rules

By default, the Partially or Fully Automatic sign on methods open one rule following successful authentication (the rule for which the sign on was initiated). For example, if a user successfully authenticates according an automatic sign on rule, the user can work with the services and destinations permitted only by that rule.

You can configure Security Gateway to automatically open all Standard Sign On rules following successful authentication using Partially or Fully Automatic Sign On. If a user successfully authenticates according to an automatic sign on rule, then all Standard Sign On rules that define that user and source are available. The user can then work with all of the services and destinations permitted by the relevant rules; the Security Gateway knows which user is at the client, and additional authentication is not necessary.

To authorize all relevant Standard Sign On Rules following successful Partially or Fully Automatic authentication, use the GUIdbedit Database Tool to change a setting in the database.

To authorize all standard sign on rules:

1. Access the GUIdbedit Database Tool from the same directory on your local drive as where SmartConsole is installed.
2. Open GUIdbedit.
3. Search for the automatically_open_ca_rules field.
4. Set the value to true. The new value takes effect after you install the security policy.

Changing the Client Authentication Port Number

To change the Client Authentication port number:

1. Stop Check Point services by running the cpstop command.
2. Modify the port number in the Manage > Service > Show > TCP Services window for the following services:
   • To modify the port number for Telnet sign on, change the port number of the FW1_clntauth_telnet service.
   • To modify the port number for HTTP sign on, change the port number of the FW1_clntauth_http service.

   These are special Check Point services provided as part of the Client Authentication feature.

3. Use a simple text editor to edit the $FWDIR/conf/fwauthd.conf file. Change the port number of the Client Authentication application to the same port number defined in step 2.
4. Do one of the following:
   • For Telnet Sign On, modify the first column in the in.aclientd line.
   • For HTTP Sign On, modify the first column in the in.ahclientd line.

21	fwssd in.aftpd wait 0

80 fwssd in.ahttpd wait 0

513 fwssd in.arlogindwait 0

25 fwssd in.asmtpd wait 0

23 fwssd in.atelnetd wait 0

259 fwssd in.aclientd wait 259

10081 fwssd in.lhttpd wait 0

900 fwssd in.ahclientdwait 900

0 	fwssd in.pingd respawn 0

0 	fwssd in.asessiond respawn 0

0 	fwssd in.aufpd respawn 0

0 	vpn vpnd respawn 0

0 	fwssd mdq respawn 0

0 	xrm xrmdrespawn0-pr

1. Ensure that there is no rule that blocks the connection to the new port.
2. Restart Check Point services by running the cpstart command.

Allowing Encrypted Client Authentication

To configure Encrypted Client Authentication for HTTPS Connections:

1. On the Security Gateway, execute cpstop on the Security Gateway.
2. Edit fwauthd.conf, located in the $FWDIR/conf directory. Add :defaultCert to the following line:

900  fwssd    in.ahclientd  wait  900 ssl:defaultCert

1. Save and close the file.
2. Run cpstart.
3. Open SmartDashboard.
4. Create this rule (which also permits HTTPS traffic between the client and the Web server):

1. Install the policy.

Continue with the following procedure using the client browser.

1. Using the client browser, enter: https:// <gateway URL>:900
2. Click Yes to trust the Security Gateway certificate.
3. Type the Security Gateway user name.
4. Click OK.
5. Click Yes.
6. Enter the gateway password.
7. Click Submit.
8. Enter the URL address: https://<Internal_Web_Server_IP_address>
9. Click Yes.

   You are authenticated on the Security Gateway and your internal Web server.

Creating Users and Groups

Authentication rules are defined by user groups, rather than individual users. Therefore, you must first define users and then add them to groups to define authentication rules. You can define users with the Security Gateway proprietary user database or with an LDAP server.

Creating User Groups

To create a user group:

1. In SmartDashboard, select User Groups from the Users and Administrators tab of the Objects tree.
2. Right-click and select New Group. The Group Properties window opens.
3. Assign the group a name.

Creating a User Template

With a template, a user inherits the template's properties, including membership in groups. If you modify a template's properties, changes only affect future users. Users previously created with that template are not affected.

To create a user template:

1. In the SmartDashboard Objects tree, open the Users and Administrators tab.
2. Right-click Templates and select New Template.

   The User Template Properties window opens.

3. Assign the template a name.
4. In the Groups tab, add user groups.

   All users in these groups will get the properties of this template.

5. In the Authentication tab, select an authentication scheme.
6. In the remaining tabs, enter the properties of the user template.

Creating Users

To create users:

1. In the Users branch of the objects tree, right-click and select Edit. The User Properties window opens.
2. Enter the user data. You can change the properties that the user inherited from the template for that user only without changing the template.

Installing User Information in the Database

Users and groups can be installed separately from the Rule Base, meaning that you can update users and groups without reinstalling the Rule Base.

To install the user database, select Policy > Install Database from the SmartDashboard menu.

Configuring Authentication Tracking

Successful and unsuccessful authentication attempts can be monitored in SmartView Tracker or using other tracking options, for example, email and alerts. Authentication tracking can be configured for the following types of authentication attempts:

• Failed authentication attempts: Can be tracked for all forms of authentication.

  To track failed authentication attempts:

• In the Authentication page of a gateway object, set the Authentication Failure Track property to define the tracking option when authentication failures occur.
• Successful authentication attempts: Can be tracked for Client Authentication.

To track successful authentication attempts:

1. In the Client Authentication Action Properties window, set the Successful Authentication Tracking property to define the tracking option for all successful Client Authentication attempts.
2. To set this option, right-click in the Action column of the Client Authentication rule. The default setting is Log.

To track all authentication attempts:

1. Select an option in the Track column of any rule that uses some form of authentication. The Set by Rule tracking option can only be added to the tracking policy set in the gateway object.

   For example, if the gateway object is set to log all failed authentication attempts, setting a rule to None has no effect and failed authentication attempts are still logged in SmartView Tracker. However, setting the rule to Alert causes an Alert to be sent for each failed authentication attempt.

Configuring Policy for Groups of Windows Users

You can create policy rules for groups of users that are not defined on the Security Management Server, but are defined either on the Windows-based gateway host or in the Windows trusted domain.

To configure policy for groups of Windows users:

1. Enable this feature using the Graphical Database Tool (GUIdbEdit).
2. Change the value of the add_nt_groups attribute to true. (This attribute is located under the firewall_properties object in the properties table.)
3. Ensure that the user belongs to a Windows user group.
4. In the SmartDashboard, create a user group with the name: Windows_<Windows user group>. The group may be empty.
5. Define a Generic User Profile for each user that uses an operating system password as its authentication scheme.