A common configuration involving SecureClient includes the ability to access Microsoft Networking services, such as Network Neighborhood, and authenticate to a Windows domain. This section covers how to get this configuration working with SecureClient.
In the vast majority of situations, enabling two options solves almost all Microsoft Networking issues, including the ability to run domain logon scripts:
Secure Domain Logon (SDL)
Office Mode was discussed previously. SDL causes SecureClient to tie into the Microsoft GINA mechanism, which means that the Windows logon process will automatically invoke SecureClient upon logging into the system. Some additional registry settings are also tweaked (namely various delays) so that the VPN authentication process along with whatever is necessary to establish an Internet connection won't cause Windows to actually time out and allow the user to log in with cached credentials.
Unfortunately, Office Mode and SDL do not work together until the FireWall-1 NG FP3 client. Also, not everyone can pony up the money required to purchase the necessary licenses for Office Mode. The rest of this section explains how to make Microsoft Networking and SecureClient work together without Office Mode.
Prior to the introduction of Office Mode, SecuRemote could be configured to forward requests for certain "domains" to go to specific DNS servers inside the encryption domain. This would allow you to use your ISP's DNS servers for Internet-based lookups but would forward all lookups for specific domains to DNS servers inside the encryption domain.
When users are logging onto a Windows 2000 Domain Controller, DNS is used for name resolution for various services. In this case, defining a SecuRemote DNS server and using SDL should be sufficient. To define a SecuRemote DNS server, go to the Servers section of the objects tree in SmartDashboard/Policy Editor, right-click on SecuRemote DNS, and select New SecuRemote DNS. You may also choose Servers from the Manage menu, click on the New button, and select SecuRemote DNS. Either way, you should see a screen similar to Figure 12.28.
Specify the name of the object (it must be unique), a comment (if desired), a color (if desired), and the host object that represents the DNS server for the domains you care about. If more than one host contains these DNS entries, you can define another SecuRemote DNS object for each host. In this example, kermit is a host object that represents the DNS server.
In the Domains tab, shown in Figure 12.29, you can define which DNS domains this object represents. Check Point uses the term label to refer to the individual words in a domain name. For instance, phoneboy.com has two labels: phoneboy and com; support.checkpoint.com has three labels: support, checkpoint, and com.
Click on the Add button to add a domain. You will see a dialog like Figure 12.30.
Only certain DNS requests will be forwarded. Using this example, if you select "Match only *.suffix," it means that a DNS request for bigbird.sesamestreet.com would get forwarded inside the encryption domain, but alan.hoopers.sesamestreet.com would not get forwarded. If you select "Match up to N labels preceding the suffix," DNS requests for the specified domain that contain the specified number of labels would get forwarded. Using the pictured example, with the option set to match up to 2 labels before the suffix, snuffleupagus.sesamestreet.com (1 label preceding the suffix sesamestreet.com) would get forwarded and mrnoodle.elmosworld.sesamestreet.com would get forwarded (2 labels preceding the suffix), but treelady.tv.elmosworld.sesamestreet.com (3 labels preceding the suffix) would not.
Once you have created the appropriate SecuRemote DNS object(s) and verified that the Encrypt DNS Traffic property is enabled in the Global Properties section, Remote Access frame, install the security policy and have your clients perform a site update.
To ensure that NetBIOS name resolution happens correctly, which is critical in a Windows NT environment, you need a WINS server that resides somewhere in the encryption domain, and it should know how to resolve all of your machines capable of speaking NetBIOS. Alternatively, you can use a well-populated lmhosts file containing names of all your NetBIOS-capable systems. However, without a WINS server, you will likely not be able to see all of these systems in Network Neighborhood.
If you have a WINS server, your SecuRemote client needs to be configured to use it. If the user accesses the encryption domain via a dial-up connection, configure it in the Dial-up Networking profile he or she uses to access the network. If the user uses a LAN card, configure the WINS server IPs on the LAN card profile. Information about lmhosts and WINS can be propagated with SecureClient. A file called $FWDIR/conf/dnsinfo.C is created. This file exists on your firewall module and allows you to send information about internal DNS and lmhosts entries to SecureClient clients as part of the network topology. The following is a sample dnsinfo.C file:
( :LMdata ( : ( :ipaddr (10.10.1.10) :name (GORDON) :domain (SESAMESTREET) ) : ( :ipaddr (10.10.1.10) :name (GORDON) ) : ( :ipaddr (10.10.1.20) :name (MARIA) :domain (SESAMESTREET) ) ) )
The dnsinfo.C file is extremely sensitive to spacing and capitalization. Use spaces where indicated in the sample shown here.
In this example, there are appropriate entries for 10.10.1.10 and 10.10.1.20. The second entry for GORDON is used explicitly for Windows 98, which requires it in order to browse the domain correctly.
Once you have created the dnsinfo.C file on your firewall modules and verified that the Encrypt DNS Traffic property is enabled in the Global Properties section, Remote Access frame, install the security policy and have your clients perform a site update.
SDL works for all Windows NT and 2000 platforms, although enabling the function requires local administrative privileges. It also works on Windows 9x platforms that connect to the Internet via a LAN adapter. SDL does not work for Windows 9x users who connect to the Internet via a dial-up adapter.