In This Section: |
If clients are configured in Connect Mode and Office Mode, clients automatically resolve the NT domain name using dynamic WINS.
Otherwise, clients resolve the NT domain name using either LMHOSTS or WINS.
Enter the relevant information (see below) the $FWDIR/conf/dnsinfo.C
file on the Security Gateway, and install the policy.
|
When the topology is updated, the name resolution data will be automatically transferred to the dnsinfo
entry of the userc.C
file and then to its LMHOSTS
file.
Users consider multiple authentications during the course of a single session to be a nuisance. At the same time, these multiple authentications are an effective means of ensuring that the session has not been hijacked (for example, if the user steps away from the client for a period of time). The problem is finding the correct balance between convenience and security.
Multiple authentication can be reduced by:
For Connect Mode, the countdown to the timeout begins from the time that the Client is connected.
To set the length of time between re-authentications:
When the timeout expires, the user will be asked to authenticate again. If password-caching is enabled, clients will supply the cached password automatically and the authentication will take place transparently to the user. In other words, the user will not be aware that re-authentication has taken place.
Password caching is possible only for multiple-use passwords. If the user's authentication scheme implement one-time passwords (for example, SecurID), then passwords cannot be cached, and the user will be asked to re-authenticate when the authentication time-out expires. For these schemes, this feature should not be implemented.
To configure password caching:
When a Remote Access client user logs on to a domain controller, the user has not yet entered credentials and so the connection to the domain controller is not encrypted.
When the Secure Domain Logon (SDL) feature is enabled, then after the user enters the OS user name and password (but before the connection to the domain controller is started), the User Authentication window is displayed. When the user enters the client credentials, the connection to the domain controller takes place over an encrypted tunnel.
When the Remote Access client computer successfully logs on to a domain controller, the user's profile is saved in cache. This cached information will be used if subsequent logons to the domain controller fail, for whatever reason.
To configure this option in the client registry, proceed as follows:
HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon
.CachedLogonCount
with the valid range of values from 0 to 50. The value of the key is the number of previous logon attempts that a server will cache.A value of 0 disables logon caching and any value above 50 will only cache 50 logon attempts.
After you have rebooted the computer:
The Logon window is displayed.
If you fail to logon and no cached information is used, wait one minute and try again.
If SDL is already configured on the client, the administrator can customize the client installation packages with SDL enabled by default.
Create a self-extracting client package using the VPN Configuration Utility and select Enable Secure Domain Logon. See the Remote Access Clients for Windows Administration Guide for details.
If a remote access client is located behind a non-Check Point firewall, the following ports must be opened on the firewall to allow VPN traffic to pass:
Port |
Description |
---|---|
UDP port 500 |
Always, even if using IKE over TCP |
TCP port 500 |
Only if using IKE over TCP |
IP protocol 50 ESP |
Unless always using UDP encapsulation |
UDP port 2746 |
Only if using MEP, interface resolving or interface High Availability |
UDP port 259 |
Only if using MEP, interface resolving or interface High Availability |
Problem:
Remote Access Clients use an internal DNS server to resolve the names of internal hosts (behind the Security Gateway) with non-unique IP addresses.
Solution:
Best practice is:
Split DNS uses a SecuRemote DNS Server, an object that represents an internal DNS server that you can configure to resolve internal names with private IP addresses (RFC 1918). It is best to encrypt the DNS resolution of these internal names.
After you configure a SecuRemote DNS server to resolve traffic from a specified domain and install policy, it takes effect. If users try to access that domain while connected to the VPN, the request is resolved by the SecuRemote DNS server. The internal DNS server can only work when users are connected to the VPN.
You can configure multiple SecuRemote DNS servers for different domains.
To configure a SecuRemote DNS server for Split DNS:
The New SecuRemote DNS window opens.
The Domain window opens,
Split DNS is automatically enabled. On Endpoint Security VPN and Check Point Mobile for Windows, you can edit a parameter in the trac_client_1.ttm
configuration file to set if Split DNS is enabled, disabled, or depends on the client settings.
To change the setting for Split DNS on the gateway:
FWDIR/conf/trac_client_1.ttm
file with a text editor.split_dns_enabled
property to the file::split_dns_enabled ( :gateway ( :map ( :true (true) :false (false) :client_decide (client_decide) ) :default (client_decide) ) ) |
:default
attribute: