Authentication Components; The Local User Database (Userdb); External Authentication Servers; Authentication Agents - D-Link NetDefend DFL-210 User Manual

8.2. Authentication Components

8.2. Authentication Components
NetDefendOS can either use a locally stored database, or a database on an external server to provide
user authentication.

8.2.1. The Local User Database (UserDB)

The Local User Database is a built-in registry inside NetDefendOS which contains the profiles of
authorized users and user groups. Users' names and passwords can be configured into this database,
and users with the same privileges can be collected together into groups to make administration
easier.
A user can be stored as a member into more than one group and any change made to the group
propagates to each group member. Passwords are stored in the configuration using reversible crypto-
graphy. This is in order to be compatible with various challenge-response authentication methods
such as CHAP. When the local user database is enabled, NetDefendOS consults its internal user pro-
files to authenticate the user before approving any user's request.

8.2.2. External Authentication Servers

In a larger network topology with a potentially large administration workload, it is preferable to
have a central database on a dedicated server or cluster of servers to handle authentication informa-
tion. When there is more than one D-Link Firewall in the network and thousands of users, the ad-
ministrator then doesn't have to maintain separate authentication databases on each firewall. Instead,
the external authentication server can validate usernames and passwords against its central database
by responding to requests from each D-Link Firewall. To provide this feature, NetDefendOS sup-
ports the Remote Authentication Dial-in User Service (RADIUS) for server authentication.
NetDefendOS, acting as a RADIUS client, sends user credentials and connection parameter inform-
ation in the form of a RADIUS message to a RADIUS server. The server authenticates and author-
izes the request, and sends back a RADIUS message in response. RADIUS authentication messages
are sent as UDP messages via UDP port 1812. One or more external servers can be defined in the
firewall.
To provide security for RADIUS messages, a common shared secret is configured on both the RA-
DIUS client and the server. This shared secret enables encryption of the user's password when the
RADIUS message is transmitted from the RADIUS client to the server, and is commonly configured
as a relatively long text string. This string can contain up to 100 characters and is case sensitive.
RADIUS uses PPP to transfer a username/password request between client and RADIUS server, as
well as using PPP authentication schemes such as PAP and CHAP.

8.2.3. Authentication Agents

Four different agents built into NetDefendOS can be used to perform username/password authentic-
ation. They are:
• HTTP - Authentication via web browsing. Users surf to the firewall and login either through an
HTML form or a "401 - Authentication Required" dialog.
• HTTPS - Authentication via secure web browsing. Similar to HTTP agent except that host and
root certificates are used to establish the SSL connection to the firewall.
• XAUTH - Authentication during an IKE negotation in setting up an IPsec VPN tunnel if the tun-
nel has been configured to require XAUTH authentication.
• PPP - Authentication when PPTP/L2TP tunnels are set up (if the PPTP/L2TP tunnel has been
configured to require user authentication).
176
Chapter 8. User Authentication