1.) Determine the applicable rule set

First of all, the NG Network Access Client determines in which context it is started and how it connects to the Access Control Service. The following three contexts are available:

Local Machine context

The local machine context is available in case no user has logged in. This applies during the startup of a Windows computer as well as after user logout.

Since the Windows system behaves different between "Current User" and "Local Machine" context it is necessary to handle the local machine context separately. For example, no popups are allowed if no user is logged in. Certificate based authentication (see below) is available for both, Local Machine and Current User Authentication, but different Microsoft certificate stores are available to get the certificates from. Of course, a Local Machine certificate must not be password protected since dialogue boxes to request the password will not be available.

Current User context

As soon as a user has logged in successfully, the client switches to the current user context. Now additional information like the user name and the password (or kerberos ticket in case of NTLM authentication) can be used to perform identity matching.

Since the user context allows to open client windows and popups, the client can notify the user about the current health state or request additional information (for example Basic Authentication: popup requests username and password).

VPN context

The VPN context is an extension of the current user context mentioned above. The client is able to determine if a Barracuda NG VPN connection was initiated as well as if the VPN server has Access Control Service capabilities. If the client mode is VPN all possibilities available in User mode are available as well. Additionally, an online and offline rule set can be assigned to the client.

2.) Client connects to Access Control Service

The next step for the client is to connect to the configured Access Control Service. The IP address of the Access Control Service is either configured manually (during installation) or is assigned by the DHCP server. The connection is based on TCP and uses port 44000 to communicate between client and server.

The connection is always initiated by the client and never the other way round.

During the handshake, the Access Control Service notifies the client of it's capabilities (for example is NTLM authentication available).

As a response, the client collects all available system information and sends this information back to the Access Control Service together with authentication credentials.

This response contains details about the computer's network (for example IP address, MAC-Address), the computer's operating system (for example OS-Version, hostname, domain name, user and certificates) as well as details about installed health suite, Antivirus, or Antispyware products.

Further policy matching on the Access Control Service depends on the data collected and sent from the client.

3.) Determine Client identity

The Access Control Service has now all information to determine the client's identity. Depending on the client mode (Local Machine, Current User, VPN) the Access Control Server determines the applicable policy rule set, which is then used to perform identity matching.

11 Barracuda NG Network Access Client - Administrator’s Guide

Page 13
Image 13
Barracuda Networks VERSION SP4 manual Local Machine context, Current User context, VPN context