Authentication

User Authentication allows individual users to authenticate to the Firebox. It is generally used to provide access control for outgoing connections.

User Authentication maps a user name to a workstation IP address, allowing the tracking of connections based on user name rather than IP address. The user's workstation must have a Java-capable Web browser. For networks using Dynamic Host Control Protocol (DHCP), this is significant. A user's workstation may have several different IP addresses over the course of a week, making it increasingly difficult to track the activities of a single user.

With User Authentication, it no longer matters what IP address is being used, or from which machine a user chooses to work. To gain access to Internet services (such as Outgoing HTTP or Outgoing FTP) the user must provide authenticating data in the form of a login and password. For the duration of the authentication, the user's name is tied to connections originating from the IP address from which the user authenticated.

Because usernames are bound to IP addresses, User Authentication should never be used in an environment where multi-user machines (such as Unix servers) are being used. Only one user per machine can be authenticated at any one time.
This makes it possible to track not only the machines from which connections are originating, but also from whom they are originating.

Other situations where authentication might be useful include education environments, such as classrooms, and college computer centers where many different people might use the same IP address over the course of the day.

Authentication Methods

Authentication is used to positively identify users and define "user" and "user group" policies. The WatchGuard LiveSecurity System can authenticate users against four authentication servers:

  • NT primary domain controllers. (A network domain is a group of computers and devices on a network that are administered as a unit with common rules and procedures.)
  • RADIUS-compliant authentication servers (as defined in RFC 2138)
  • CRYPTOCard authentication
  • WatchGuard's built-in authentication server (Firebox domain)
The differences among the various authentication schemes are largely transparent to the user; the user performs the same sequence of tasks to be authenticated against any of the four types of authentication.

The difference for the Firebox administrator is that in one case the database of usernames, passwords, and groups are stored on the Firebox itself, and in the other cases, the usernames, passwords, and groups are stored on the server performing the authentication--Windows NT server, Radius server, or CRYPTOCard server.

In the case of an external authentication server, you must set up that server according to the manufacturer's instructions and place it on the network so it is accessible by the Firebox.

Only one type of User Authentication may be used at a time.

If you already are using a Windows NT Domain Controller, you may want to continue using that for user authentication for services other than Mobile User VPN.

In addition, there are two Global Authentication Settings:

  • Logon timeout where you select how many seconds are allowed for an attempted logon before the timeout shuts down the connection
  • Session timeout where you set how many hours a session can remain open without keystrokes before the timeout shuts down the connection.

The WatchGuard Authentication Implementation

To authenticate using any Java-enabled Web browser such as Netscape Navigator or Microsoft Internet Explorer, users first query an authentication daemon on the Firebox. A micro-WWW server on the Firebox then sends a Java applet back to the user, wherein name and password information is entered. This information is encrypted within the applet and passed back to the Firebox for verification against the authentication server defined in its configuration. As a result, the system authenticates users just once, instead of each time they attempt to connect to a site. User name and password information needed for authentication is never passed in clear text.

Authentication is particularly crucial when you use dynamic IP addressing (DHCP) behind the Firebox, or want users to identify themselves before performing various services through the Firebox. With the WatchGuard LiveSecurity System, authentication can be configured on a service-by-service basis allowing users to only need to authenticate for certain services.

WatchGuard offers full inter operability with standards-based authentication technology from CRYPTOCard for both CRYPTOAdmin and RB-1 Tokens. This enables you to secure network access using powerful token-based authentication solutions from CRYPTOCard, in conjunction with the WatchGuard LiveSecurity System.

The built-in authentication server included with the WatchGuard LiveSecurity System is designed for smaller environments. User names, group names and passwords can be entered directly into the Firebox configuration to set individual filter rules as desired.

Firebox Authentication

Usernames, passwords, and groups may also be stored in the Firebox. These accounts are also used for Mobile User VPN.

For NT Domain Controller or Radius authentication, you must enter the users and/or groups on the respective Windows NT or Radius authentication servers. For Firebox Domain accounts, however, you perform all authentication setup on the Firebox Users tab of the Member Access and User Authentication Setup dialog box.

In configuring Firebox authentication, you can define users and groups, and assign members to specific groups.

Two WatchGuard authentication groups are included for a VPN connection with only one Firebox at the home office. The group "ipsec-users" is a special built-in group that contains only currently authenticated Mobile User VPN users. The group "pptp-users" is the equivalent for remote users connecting to the Firebox with PPTP. You must add user names to the appropriate group to enable them to use Mobile User VPN or PPTP to remotely connect to the Firebox.

Windows NT Authentication

Windows NT Domain User Authentication is based on NT Domain Users and Groups, and uses the User and Group database already in place on your Windows NT Domain Controller.

WatchGuard's implementation of authentication via a Windows NT server assumes you have configured your Windows NT server with users and groups. You can configure these parameters when setting up Windows NT authentication for WatchGuard:

Host Name
The host name of the NT server you want to use for authentication.

Automatic IP Address Lookup
You can configure WatchGuard to look up the IP address for the Windows NT domain host name.

Use Local Groups
You can use the Windows NT server organization of users and groups.
  You cannot use local groups for Windows NT authentication if your administration workstation is a Windows 95 host. Windows 95 does not support the ability to gather the list of local groups from a computer running Windows NT. You must run SMS from a Windows NT host to configure local groups in your rule sets.

Radius Authentication

The Remote Authentication Dial-In User Service (RADIUS) provides remote users with secure access to corporate networks. RADIUS is a client-server system that stores authentication information for users, remote access servers, and VPN gateways in a central user database available to all servers. Authentication for the entire network happens from one location. RADIUS prevents hackers from intercepting and responding to authentication requests by transmitting an authentication key that identifies it to the RADIUS client. Note that it is the key that is transmitted, and not a password. The password resides on the client and server simultaneously. That is why it is often called a "shared secret."

Before RADIUS, user authentication was stored on each remote access server on a network. Each server had to be individually configured, making security policies and the user database hard to maintain. RADIUS has access to multiple servers, and centralized configuration and control. This simplifies its links with existing network operating system authentication information (for example, Windows NT User Domain or Novell NetWare Direct Service trees). It also makes it easier for remote access software from multiple vendors to work well together.

The RADIUS server stores and forwards session configuration information on an individual, user-by-user basis, so users gets the same service parameters regardless of the server they connect to.

For Radius authentication, you must enter the users and/or groups created for the individual service properties and the IP address of the Firebox on the Radius authentication server.

WatchGuard's implementation of Radius authentication enables you to configure these parameters:

IP Address
The IP address of the machine you are using as a Radius server.

Port
The port number the Firebox will use for Radius authentication.

Secret
The password that will function as a shared secret between your Firebox and the Radius server. The secret is case-sensitive and must be exactly the same as the one entered on the Radius server.

Backup radius server
You can specify a second Radius server as a backup for Radius authentication when your primary server is unavailable. The backup must have the same shared secret as the administration host and the primary Radius server.

WatchGuard Radius works only with CHAP (Challenge Handshake Authentication Protocol) authentication. Make sure your Radius server supports CHAP.

CRYPTOCard Authentication

CRYPTOCard is a hardware-based authentication system that allows users to authenticate via CRYPTOCard's challenge response system which includes offline hashing of passwords. It enables you to authenticate individuals independent of the hosts they are on.

Configuring WatchGuard CRYPTOCard server authentication assumes that you have acquired and installed a CRYPTOCard server according to the manufacturer's instructions, and that the server is accessible for authenticating to the Firebox.

The WatchGuard implementation of CRYPTOCard Server enables you to configure these parameters:

IP Address
The IP address of the machine you are using as a CRYPTOCard Server.

Port
The port number the Firebox will use for the CRYPTOCard Server. The port number does not usually need to be changed from the default, 624.

Administrator Password
The CRYPTOCard server`s administrator password as found in the CRYPTOCard server's "Passwd" file.

Timeout
The length in seconds for the timeout period. The timeout period is the maximum amount of time you can wait for the CRYPTOCard server to respond to you. CRYPTOCard's recommended timeout is 60 seconds.

Secret
The keyword that will function as a shared secret between this Firebox and the CRYPTOCard server. This is the key or client key in the "Peers" file on the CRYPTOCard server. The secret is case-sensitive and must be exactly the same as the one entered on the CRYPTOCard server. This will be used to encrypt the session between the Firebox and the CRYPTOCard server.
  When implementing a CRYPTOCard authentication scheme, you must also add the Firebox's IP address and the users or groups to authenticate to the CRYPTOCard server's configuration file. The Firebox is entered as a client to the CRYPTOCard server. For more information, see your CRYPTOCard server documentation. Only one alias/group is supported by the CRYPTOCard server.

How CRYPTOCard Authentication Works

There is a mini-HTTP server running on the Firebox on port 4100 at http://[Firebox trusted interface IP]:4100. In order to authenticate, users must connect to this authentication server using a web browser (that supports Java) to this URL: http://[Firebox trusted interface IP here]:4100/.

This loads a Java applet that prompts for a username and password. Once the user successfully types in a matching username and password, the Java applet displays an authentication string in the form of a number. The user then enters this number into his CRYPTOCard. The CRYPTOCard processes the number and issues a second number. The user then enters this number in a second space on the Java applet's user interface. This number is transmitted to the CRYPTOCard server, which then authenticates the responding number. In doing so, CRYPTOCard takes the basic authentication of Radius and adds stringent levels of authentication. With CRYPTOCard authentication, one cannot use a Web browser to access sites on the External interface without possession of a CRYPTOCard. The CRYPTOCard must be set up and registered with the CRYPTOCard server. Furthermore, one cannot use a CRYPTOCard to perform the number entry and response without keying in the correct user identification and password on the CRYPTOCard itself.

Once they are successfully authenticated, users can then minimize the Java window and begin browsing the Web. As long as the Java window remains alive (that is, it can be minimized but not closed), users remain authenticated. If they click the Close button in the Java window or close their browser completely, they are no longer authenticated.

Removing Authentication

The only way to prevent selected accounts from being able to authenticate is to disable their accounts on their respective authentication servers--the NT Controller, Radius Server, or on the Firebox. A user can remain connected for up to 24 hours before being automatically disconnected. The same applies to CRYPTOCard, except you can also confiscate the user's CRYPTOCard itself, which renders authentication impossible for that user.

Configuring an Authentication Environment

One way to create effective User Authentication environments is to restrict all Outgoing services to only allow connections From Authenticated Users. For example, using Windows NT Server, you would create a Group on the Windows NT server that contains all the User accounts. Then you would add that group name to the Internal hosts for the Outgoing or Proxy service in the WatchGuard Policy Manager.

Combining User Authentication and Mobile User VPN

When a Mobile User VPN connection is made to the Firebox, the client's username and password are checked against the Firebox Domain only. For this reason, Mobile User VPN users must have an account in the Firebox Domain, and must be a member of the ipsec-users group for access, regardless of any other authentication scheme in use. If they use a PPTP connection, they must be a member of the pptp-users group.

When users authenticate using their account in the Firebox Domain, WatchGuard automatically adds their IP address to all Firebox Domain groups of which they are a member (and conversely removed when they end their authentication).

ipsec-users is a built-in Firebox Domain Group where you must enter all currently active Mobile User VPN users. When a user successfully connects to the Firebox using Mobile User VPN, WatchGuard automatically adds the assigned ipsec-users address to the username to this built-in alias. When the user shuts down the Mobile User VPN session, WatchGuard automatically removes the user's address associated with that user from the ipsec-users alias.

pptp-users is the other built-in Firebox Domain Group. From a configuration standpoint it works like ipsec-users and Mobile User VPN, except that it is for remote users who access the Firebox with PPTP instead.

By default, Mobile User VPN users, PPTP users or any other users have no access privileges through a Firebox. To allow Mobile User VPN or PPTP users to access machines on the Trusted network, you must add their usernames (or the ipsec-users or pptp-users group alias, respectively) to service icons in the services arena.

A typical use of a remote user gropu is to allow incoming connections to certain Trusted servers from the ipsec-users group members. This is an easy way to provide outside access to critical machines inside your network without risking your general security.

For example, to allow outgoing telnet, but only allow incoming telnet if the request comes from a Mobile User VPN user, you would

  • Add the telnet service to the WatchGuard Policy Manager
  • Configure the outgoing direction only to allow telnet traffic from any internal host to any outside host.
  • Configure incoming direction to allow traffic from the ipsec-users group to any internal host.
 

 

Install | User | Handbook | Reference | Training | Support | Archive | Contact Us
Copyright © 1998 - 2001 WatchGuard Technologies,Inc. All rights reserved.
Legal Notice/Terms of Use