Explanation:
Required Sign On The Required Sign On option determines whether a user can be authorized for all destinations and services specified by the rule (the Standard option), or whether a user must specify the destinations and services he or she wishes to access during client authentication (the Specific option). If the Standard option is chosen in Figure 7.23, the user can choose either the Standard Sign On or Specific Sign On options during authentication. If the Specific option is chosen, the user cannot choose the Standard Sign On option during authentication .
Sign On Method
The sign on method determines how a user actually authenticates with the VPN-1/FireWall-1 enforcement module for client authentication. The following describes each option: Manual This is the default setting, and means that a client must initiate a client authentication session with the enforcement module using either TELNET to port 259 or HTTP to port 900, before the user can access the destinations and services specified in the rule. So far in this section on client authentication, the manual sign on method has been described. Partially Automatic This option, also known as implicit client authentication, allows users to use user authentication using HTTP, FTP, TELNET, or RLOGIN in place of the manual client authentication process described above. If a connection matches the client authentication rule that is HTTP, FTP, TELNET, or RLOGIN based (i.e., a user authentication service), authentication is performed in-band using user authentication via the security servers on the enforcement module. If user authentication is successful, the client is then authorized for the client authentication rule (including services outside of the user authentication services). If users wish to establish a connection permitted by a client authentication rule that specifies a partially automatic sign on method, and the connection is not a user authentication service (i.e., HTTP, FTP, TELNET, or RLOGIN), you must use the manual client authentication sign on method before attempting the connection. Choosing this option enables you to perform client authentication using a user authentication mechanism rather than manual client authentication. For example, a user may need to access a TELNET server behind a gateway, and also access an SQL server. If you want to authenticate this access, you can't use user authentication, as the SQL access cannot be authenticated using this method. If you created a partially automatic client authentication rule, which permitted TELNET access to the TELNET server and SQL access to the SQL server, the user could first authenticate with the enforcement module using TELNET-based user authentication. This would not only grant the client access to the TELNET server, but would also authorize the client for access to the SQL server. See "Providing Transparent HTTPS Authentication" Real World sidebar for another example of where you might configure this option. Fully Automatic This method uses the session authentication agent to provide authentication for the client authentication rule. If a new connection matches a client authentication rule that is currently not authenticated for the requesting client, the enforcement module will invoke session authentication back to the requesting client. Once the user successfully authenticates via session authentication, all destinations and services permitted in the client authentication rule are authorized for the client IP address. Note that the client must have the session authentication agent installed. Agent Automatic Sign On This is similar to the fully automatic sign on method, except all services are authenticated by the session authentication agent, including HTTP, FTP, TELNET, and RLOGIN. The client must have the session authentication agent installed. Single Sign On Systems This method is used in connection with Check Point's optional address management product, which maps users to IP addresses on the network. If a connection request matches a client authentication rule with this sign on method, the address management database is referenced to determine the user associated with the IP address. If the user currently associated with the IP address is a member of any of the permitted user groups in the Source element of the rule, the client IP address is authorized for the rule. This method involves no authentication at all from a client perspective, as authentication has previously occurred that has mapped the user to an IP address in the address management database.