Authenticity of the certificate authority is verified by the fingerprint. To verify the CA fingerprint, follow these steps:
1. On the Active Directory server (or your CA), run the Certification Authorityconsole.
2. In the Issued Certificateslist, double-click the certificate issued to the domain controller serving as the LDAP account unit.
3. In the Detailstab, click Copy to File....
4. Make sure the DER encoded binary X.509(.CER)option is selected and click Next.
5. Specify a name for the file that the certificate will be written to.
(The extension .CER will be added automatically.)
6. Click Finishand then click OKto close the Certificate Export wizard.
7. Use any MD5 utility to calculate the exported file’s MD5 finger- print. The fingerprint fetched in the Encryption tab of LDAP Account Unit should be compared to the output string.
Tools & Traps…
To use IKE preshared secrets or public key certificates, you should use user tem- plates. When SecureID is used, usernames are checked against the user’s AD personal identification number (PIN) and the tokens are checked against the ACE server.There are other user control options, such as limiting login failures in the Authentication tab.
Secure Authentication API (SAA) supported applications can also be integrated with Active Directory.
S/Key is not an option in Default Authentication Schema, since it cannot be used globally. It is not recommended that you use S/KEY in security policy authentication rules, since S/Key authentication will be phased out by the upcoming FP4 release.
When an IKE secret key is used for SecuRemote users, the user’s password must be stored encrypted in the Active Directory database.To do this, first define the secret key in the account unit by selecting the Properties | Authentication | Encryption | IKE pre-shared secret authentication keyfield (see Figure 3.46).Then you can generate the encrypted passwords with the fwm ikecrypt command.The resulting string is then stored in Active Directory.The syntax for fwm ikecryptis as follows:
#fwm ikecrypt SharedSecret userpassword
After you finish configuring your account unit, you will notice that your LDAP tree appears on the Users and Administrators tab of the Objects tree (see Figure 3.47).
When you open the tree by double-clicking it, you will see your Active Directory users and groups in your SmartDashboard.
Figure 3.46 The LDAP Account Unit Management Authentication Tab
Configuring LDAP Administrators
Once you define your Active Directory unit and establish the connection to it,
SmartDashboard becomes your user manager, or the Active Directory User Management console becomes your VPN-1/FireWall-1 user management console.Your changes on both consoles will take effect on the Active Directory database that is defined as your account unit. VPN-1/FireWall-1 assumes that all servers in the account unit are repli- cated, and it does not control the accuracy of the data in the AD servers. Access order to the account units is based on the priorities. When there are identical priorities, round- robin load distribution is used.
Generally, firewall administrators do not handle user management. Assigning access privileges in SmartDashboard can be a problem, especially when you have multiple administrators with different access rights.To handle this problem, you should define specific LDAP administrators in the SmartDashboard user management interface and delegate only LDAP user database Read/Writeor Read Only access to these users.
With these options, LDAP administrators will not be able to make changes to the secu- rity policy.You may define a specific permission profile from the Manage |
Permission Profilesmenu.Then you can define multiple account units with different DNs. In the Object Managementtab of account unit descriptions, check Prompt for password when opening this Account Unitto enable password protection on user databases.
Figure 3.47 Displaying Active Directory in SmartDashboard
User Management on Active Directory
You may use SmartDashboard to manage your users in Active Directory.To do so, follow these steps:
1. From your SmartDashboard, open the Object tree and go to Users | Your AD Tree | Users. Select New Group from the context menu to create a new user group (see Figure 3.48).
2. You will see that the group AD_Users has been created in the
SmartDashboard central pane, as shown in Figure 3.49. If you open the AD user management GUI, you will see that the group information is accessible from there as well.
3. You are now able to use the group you have created.To define the group members, choose an existing user from the SmartDashboard, as displayed in Figure 3.50, and add the user to the groups that you have created.
4. Open your Active Directory Users and Computersconsole on your AD server and verify the changes on the Active Directory database (see Figures 3.51 and 3.52).
Figure 3.48 Group Properties
Figure 3.49 Displaying Users from SmartDashboard
You may conduct further tests on bidirectional interaction. Since SmartDashboard and Active Directory Native interface interact with the same data source, all changes will be transparent to users on both sides.
Figure 3.50 Modifying User Groups from SmartDashboard
Figure 3.51 Displaying Changes in Active Directory
Figure 3.52 Group Details in Active Directory
Configuring the Rule Base
When you complete your Active Directory Integration, you may use the Active Directory user groups in your Rule Base for authentication.
1. To use your users and groups in your VPN-1/FireWall-1 Rule Base, define an LDAP group (see Figure 3.53) from Object Tree | Users | LDAP Group or the Manage | Users menu.The advantage of creating these groups is the ability to limit their scope. Defining LDAP groups allows you to apply gran- ular filters on your LDAP users through a defining scope. In the following example, only users from the AD_Users group are allowed to be members of the LDAP group.
NOTE
Define external groups only if they are actually used in your Rule Base. LDAP enforces membership rights for user groups.
2. As shown in Figure 3.54, verify encryption properties from user properties.
Use of user templates is recommended when a large number of users will be defined through SmartDashboard.
3. Check your VPN-1/FireWall-1 gateway’s configuration before pushing policy.
As displayed in Figure 3.55, your gateway must support the encryption and authentication schemes used by your users. If you are using a policy server for SecureClient authentication, the AD user group must be listed under the Policy Server | Users drop-down menu of your gateway object’s properties.
Figure 3.53 LDAP Group Properties
4. If you use remote access communities for SecuRemote or SecureClient, users using simplified security policies will ease the configuration (see Figure 3.56).
To allow remote access, simply add the participating user groups to the Remote Access Community page.
5. Configure your Rule Base and add the authentication (see Figure 3.57). Allow your LDAP user group to access services via the Remote Access community.
On the client side, your users will be authenticated against Active Directory, and as shown in Figure 3.58, you will get successful authentication entries in SmartView Tracker. For Remote Access, SmartView Tracker generates detailed troubleshooting information on the Info tab.
Figure 3.54 LDAP User Properties
Figure 3.55 The Gateway Properties Authentication Tab
Troubleshooting
This section describes some problems you might run into and some of the possible solutions for them.
Schannel.dll Error
If you are receiving an schannel.dll error (with a source of Schannel) in the Windows 2000 Event Viewer logs (see Figure 3.59), there are two possibilities for what is happening:
■ You do not have the Windows 2000 High Encryption Pack.
■ You did not set the minimum or maximum encryption strength to Highin the LDAP Server Properties | Encryption tab.
Figure 3.56 Remote Access Community Properties
Figure 3.57 Configuring the Rule Base for Remote Access
Figure 3.58 SmartView Tracker Output for Successful Authentication
Unable to Find the Correct User Group in Active Directory
If you have difficulty finding your users in Active Directory, you have more than one option on VPN-1/FireWall-1.You may use either the GUI, as displayed in Figure 3.60, or the command line.The Ldapsearchcommand uses RFC-1558 compliant LDAP search filters. Or you can go to the Search | Query LDAP objectsmenu and enter your search query.The results will be listed in SmartDashboard.
Suggested Uses of MS-AD Authentication
Active Directory and VPN-1/FireWall-1 integration could be useful in the following scenarios:
■ You have an enterprise MS AD implementation and you do not want to duplicate your efforts for user management on the firewall.
■ High availability and geographical load balancing are your prerequisites.
■ You do not want to deal with user database administration issues such as repli- cation or backup.
Figure 3.59 The Schannel Error Message
Figure 3.60 LDAP Query Search
■ You need to access your user database from various interfaces.
■ Your requirements include development and modifications of the user man- agement system.
■ Your security policy requires separation of duties for user management.
■ You want to utilize existing tools and solutions that are already available for Active Directory.
MS Active directory is not recommended if you are not familiar with the Microsoft platform. In any event, remember that SmartClient Administrator access cannot be authenticated against Active Directory.