SSL Web Portal - End of Life

As of AXS Guard version 11.1.0, it is important to note that the SSL Web Portal feature will no longer be supported. To ensure a seamless and secure transition, we strongly advise using our Remote Workspace solution as a suitable alternative. Remote Workspace provides enhanced functionality and robust security measures that will effectively meet your needs.

Introduction

About this Document

This manual is intended for system administrators and describes how to configure and use the AXS Guard SSL Web Portal. It is not intended as a complete reference guide and does not explain all possible configuration options and features. It is intended as a quick installation and user guide for frequently used options.

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

General SSL Web Portal Concepts

The SSL Web Portal Agent

The SSL Web Portal is a browser based remote access and control solution. It allows Users to remotely, but securely, access (for example) an organization’s email or intranet, functionalities and Resources.

The SSL Web Portal relies on JAVA™ Web technology and therefore requires a JAVA-enabled Internet browser for access. No other client-side software is required on the user’s system. All network traffic is encrypted (HTTPS) and administration is centralized and simple.

The SSL Web Agent is a small JAVA application used by certain types of resources. It provides a secure communication channel between a remote client and the SSL Web Portal. All data sent and received by a resource is tunneled through this secured channel. The agent is automatically launched whenever it is required by a resource. It can also be launched manually.

Access Controls

In the SSL Web Portal, Users and Groups are assigned to Policies. Resources, such as Tunnels, Network Shares and Applications are assigned to Policies. Policies therefore act as the link between Principals (Users and/or Groups) and the Resources which they can use (see image below).

Configuring access for Users to different Resources requires the following steps by an Administrator in the SSL Web Portal Management Console:

1. Installing the extension or plug-in for the required Resource.

2. Configuring the Resource appropriately.

3. Assigning access rights for the Resource to Users and Groups through creation of one or more Policies and assigning the Policies to the Resources.

Users and Groups

AXS Guard Users and groups are automatically synchronized with the SSL Web Portal (if SSL Web Portal access is enabled for the user or group).

Administrators and Users

A user with basic, full or advanced administrator rights in the AXS Guard Administrator Tool and SSL Web access, automatically has administrator privileges when logged in to the SSL Web Portal.

Administrators vary from users as follows:

• There are console types in the SSL Web Portal, i.e. the user console and the management console). Users only have access the user console, whereas administrators can access both.

• Users can use applications, manage favorites, edit attributes and profiles. Administrators additionally can:

  • create, edit and delete users and groups in the AXS Guard Administrator Tool.

  • create, edit and delete resources, policies, profiles and attributes in the SSL Web Portal.

  • view users and groups and assign resources to them in the SSL Web Portal.

Extensions

The SSL Web Portal functionally can be extended using plug-ins, called ‘extensions’. Extensions allow SSL Web Portal Administrators to install new or upgrade existing Resources. Once a plug-in is installed, it is available for Administrators to configure and assign access rights for Users and Groups. It is not possible to configure settings and access rights for a Resource unless its extension has been installed.

Resources

Resources are the functionalities which the SSL Web Portal makes available to remote Users. Resources which can be used via the SSL Web Portal include:

• Web Forwards: these Resources provide access to applications which are browser-based.

• Network Shares: these Resources provide access to internal FTP Servers and Windows Shares.

• Applications: these Resources provide access to applications on your internal network, e.g. Wake-on-LAN and Microsoft and JAVA RDP applications.

• Tunnels: these Resources can be used for applications on your network which are none of the above, i.e. not browser-based or Network Shares, have no default application available, and which use a TCP/IP connection towards the application server.

SSL Web Portal Access Controls

Authentication

Authentication requests are handled by AXS Guard, using DIGIPASS and/or static passwords. AXS Guard authentication is managed by Security Policies, which implement a combination of rules, for example, whether a user must use a DIGIPASS One-Time Password in combination with a static password for authentication.

Info

• Able recommends 2FA, as this is the most secure option.

• Tokens must be assigned to users using the administrator tool; see the AXS Guard Authentication How To for instructions.

Attributes

Attributes are fields or variables created by Administrators in the Management Console. Two types of Attribute exist:

• User specific: values for the Attribute are defined by Users. An example is a User Password.

• Policy specific: values for the Attribute are defined by Administrators and operate for all Users assigned to the Policy.

Attributes simplify configurations, for example Administrators can use:

• a Password Attribute for Single Sign On in a Resource configuration.

• an Attribute to define a User-specific field, which Users can then define themselves. For example, by creating an Attribute for IP Address, Administrators avoid needing to create a Resource for each User account with the User IP address as Location. Instead, only one Resource needs to be created with the Attribute as Location. Each User can then configure their IP address as the Attribute value.

Info

• A User Attribute value overrides a default value specified by the Administrator.

• Policy Attributes are assigned to all Users belonging to a Policy.

Policies

Policies act as the link between Principals (Users and or Groups) and the Resources which they can use (see image below). Administrators need to:

• identify which Users need to use which Resources

• create Policies which allow Resources to be applied to Users and Groups appropriately.

Example: Using policies

Sales need to use the Intranet Web Forward; Accounts needs to use the Wake-on-LAN Application; some members of Sales and some members of Accounts also need to use both the Intranet and the Wake-on-LAN (illustrated below).

To organize these Resource Access Rights:

1. Create Policy 1, which includes all members of the Sales Department.

2. Create Policy 2, which includes only the members of Sales and Accounts who will be allowed to use both Resources.

3. Create Policy 3, which includes all members of the Accounts Department.

4. Assign Policies 1 and 2 to the Intranet Resource.

5. Assign Policies 2 and 3 to the Wake-on-LAN Resource.

   

IP Restrictions

Administrators can grant or deny access to the SSL Web Portal VPN server by specifying restriction rules based upon the client’s IP Address. Wildcards may be used to grant or deny access by subnet, e.g. 192.168.1.*.

Info

You can achieve the same result by adding a firewall rule on the AXS Guard. See the Firewall How To for information about adding rules.

SSL Web Portal Resource Types

Web Forwards

A Web Forward is used to allow access from the Internet to a Web server or Web-based application located in your LAN over a secured connection (SSL). After authentication on the SSL Web Portal, authorized Users can click on the Web Forward Resource icon to gain access to the Web server. By creating such a forward, the administrator(s) can make a private Web Resource securely accessible from the outside world. Typical examples include, but are not limited to, an Intranet Web server or an Outlook Web Access.

There are three types of Web Forwards:

• Replacement Proxy

• Reverse Proxy

• Tunneled

Replacement Proxy

Replacement proxies are suitable for Web applications which use fully-qualified URLs with minimal JAVAscript. The concept of the replacement proxy configuration is shown in the image below which cross-references to the numbered steps described here:

1. The client requests a Web page on an internal Web server using the SSL Web Portal.

2. The SSL Web Portal sends the request to the Web server.

3. The response is received from the Web server. All links, code (HTML) and headers in the response are rewritten to point back to the AXS Guard, rather than the source Web server.

4. The rewritten response is returned to the client.

Clicking on a link in the returned Web page (whether towards an internal or external Web server) initiates a connection request through the SSL Web Portal, i.e. these requests are also processed and protected by the SSL Web Portal.

Info

A fully-qualified URL is a URL which is independent or free from any relationship. A fully-qualified URL describes the protocol to use, the server to contact and the file to request (see image below). Hence, a fully qualified URL specifies the exact location of a file or directory on a Web server, e.g. http://webserver.example.com/testing/index.htm

Reverse Proxy

Reverse Proxy Web Forwards are suitable for Web applications:

• which use absolute and relative URLs, and

• which require access control.

The concept of the Reverse Proxy configuration is shown in the image below which cross-references to the numbered steps described here:

1. The client requests a Web page on an internal Web server using the SSL Web Portal.

2. If the requested Web page is not restricted, the SSL Web Portal sends the request to the specified internal Web server (Access control is explained below).

3. The response is received from the Web server. The headers in the response are rewritten to point back to the AXS Guard, rather than the source Web server. Links and code (HTML) are not rewritten.

4. The rewritten response is returned to the client.

   • Clicking on a link in the returned Web page pointing towards an external Web server initiates a direct connection without using the SSL Web Portal. This direct connection is therefore not secured by the SSL Web Portal.

   • Clicking on a link in the returned Web page pointing towards another internal Web server does not work since the address provided in the link is unlikely to function outside the secure network (e.g. an internal DNS name or a private IP address).

   

Access Control

• Path-based restrictions are supported by the AXS Guard.

• Path-based Reverse Proxies only allow requests for specific paths.

Example: Path-based Reverse Proxy

All Outlook Web Access Web pages can start with the following paths:

• http(s)://<owaserver>/exchange/....

• http(s)://<owaserver>/exchweb/....

• http(s)://<owaserver>/public/....

A URL request not matching one of these paths is likely to be a hacking attempt and should be restricted. Permitted paths are defined in the Path-based Reverse Proxy configuration.

Info

1. Path-based Reverse Proxy configurations only work if all allowed Web pages start with a specific path (see the example above). A page at the root of the Web server may not be allowed.

   • http://www.example.com would be rejected, whereas

   • http://www.example.com/salesportal would be accepted.

2. An absolute URL points to a file or location on a server without describing the protocol and the server. An absolute URL starts with a slash, followed by the path(s), and ends with the filename, e.g. /testing/index.html

3. A relative URL points to a file or directory in relation to the present file or directory, e.g. ../index.html

Tunneled Web Forward

If Replacement or Reverse Proxy Web Forwards don’t work, a Tunneled Web Forward is the last resort. This type of Web Forward can be used when a website is non-RFC compliant. The concept of a Tunneled Web Forward configuration is shown in the image below, which cross-references to the numbered steps described here:

1. The client requests a Web page on an internal Web server using the SSL Web Portal.

2. A tunnel is opened directly between the application and the client.

3. Nothing is rewritten in the response.

4. The response is returned from the application to the client directly through the tunnel.

   • Clicking on a link in the returned Web page pointing towards an external Web server initiates a direct connection without using the SSL Web Portal. This direct connection is therefore not secured by the SSL Web Portal.

   • Clicking on a link in the returned Web page pointing towards another internal Web server does not work since the address provided in the link is unlikely to function outside the secure network (e.g. an internal DNS name or a private IP address).

   

Info

A tunneled Web Forward requires a running SSL Web Agent on the client to terminate the secured channel.

Network Places

Network Places are used to securely access files, folders and directories within a corporate network. Remote Users can browse shared folders, rename, delete, retrieve and upload files as they would locally. The SSL Web Portal provides the possibility for remote users with the appropriate permissions to browse, for example, Microsoft file shares and SAMBA file systems configured on UNIX. An option automatically detect simplifies the configuration.

Applications

An Application Resource is used to make an application available through the SSL Web Portal. This means an application can be accessed easily by authorized clients and prevents the need to install specific application software on every client. An application is only available if the extension associated with it is installed.

If no extensions are installed, no application shortcuts can be created. Extensions can be installed using the Extension Manager

Example applications include:

• the Wake-on-LAN application

• JAVA RDP clients

• Microsoft RDP clients

• the Citrix client

Tunnels

SSL Tunnels provide a solution when a customized application (for example an order management system):

• is not a Network Share or Web-based

• has no default application available in the SSL Web Portal Extension Store

• uses a TCP/IP connection towards the application server.

SSL Tunnels allow ad-hoc connections between networked computers. An SSL Tunnel is a connection between two TCP enabled components. All of the data transmitted over a tunnel are encrypted using the SSL protocol.

Two types of SSL tunnels exist, providing the same functionality in different directions:

• a local SSL tunnel allows a remote User to connect to a port behind the SSL Web Portal (for example a service or device in the secure LAN, such as a database server).

• a remote SSL Tunnel allows a User in the LAN to connect to a service on the remote client (for example to provide remote support to a User).

Setting up an SSL Tunnel requires three steps: . Installing the client software on the PC which will be making the requests towards the application. . Creating a local tunnel, for example towards a database. . (Optionally) configuring Agent Profile settings to automatically open the tunnel on successful logon to the SSL Web Portal. If the Tunnel is not configured to open automatically on successful logon, it must first be opened manually before the application is started. Using an SSL Tunnel requires a running SSL Web Portal Agent.

Profiles

• Profiles define session and Agent settings on logon.

• Session settings define how the user interface appears for a user (e.g. with icons or listings) and certain security settings such as the SSL Web Portal timeout.

• Agent settings define, for example, whether the Agent starts automatically on logon.

If more than one Profile is available, Users can select a default Profile to be assigned on logon, or to choose a Profile on logon.

Installation Procedure

Overview

The SSL Web Portal is installed and configured through the AXS Guard Administrator Tool. In this section, we explain how to:

• activate the SSL Web Portal Feature

• configure SSL Web Portal server certificate and settings

• create a user with administrative privileges to manage the SSL Web Portal

• grant SSL Web Portal access to users and groups

• configure how users must authenticate to access resources on the SSL Web Portal

Activating the SSL Web Portal Feature

1. Navigate to System > Feature Activation > VPN.

2. Check the box against Do you use the SSL Web Portal option?

3. Update your configuration.

Server Configuration

Connection Settings

1. Log in to the AXS Guard as a basic administrator or above.

2. Go to VPN > SSL Web Portal > Server.

3. Configure the web portal settings as explained in the tables below.

4. Update your configuration when finished.

   

Option	Description
Enable	Enables and starts the SSL Web Portal. Ensure that no other service is using the configured TCP port, otherwise the service will fail to start.
Bind to	The SSL Web Portal will bind to the selected interfaces. All Interfaces: The SSL Web Portal will be accessible via all interfaces (secure, DMZ and Internet). All Internet and DMZ interfaces: The SSL Web Portal will only be accessible via Internet and DMZ interfaces. All Internet interfaces: The SSL Web Portal will only be accessible via Internet interfaces (system default). Custom configuration: Allows you to select specific devices and/or IP addresses.
Interface	This field only appears if you selected "custom configuration". Select and add the interface(s) on which the SSL Web Portal must listen for incoming connections. This option is especially useful with dynamically assigned IPs.
Bind to IP	This field only appears if you selected "custom configuration". The SSL Web Portal will bind to the specified IP(s). You can use this in case you have network devices with IP aliases and you wish to use an IP alias for the SSL Web Portal.
TCP Port	Enter the desired server port. TCP 443 is the system default port. Avoid port conflicts. If another service is using TCP port 443, for example the webmail or reverse proxy service, the SSL Web Portal will fail to start. Change the port number in that case.

Security Settings

Option	Description
Server Certificate	Select the server certificate for the SSL Web Portal. Go to PKI > Certificates to create or import a server certificate.
Current Certificate	Shows the certificate details of the selected server certificate.

SSL Web Portal Administrators

Users with any level of AXS Guard administrator rights (basic or above) and SSL Web Portal access are automatically assigned administrator rights in the SSL Web Portal.

1. Log in to the AXS Guard as an administrator.

2. Go to Users & Groups > Users and click on "Add new".

3. Make sure the new user has at least basic administrator rights.

   

4. Select to the VPN tab and enable SSL Web Portal access (or make sure the administrator has the necessary privileges assigned in the group (s)he is a member of).

5. Update your configuration.

   

Info

See the AXS Guard System Administration How To for more information about creating users and groups.

SSL Web Portal Users and Groups

AXS Guard groups and users are automatically created and removed on the SSL portal. Note that users must be specifically granted access to the SSL portal. Groups without members are also automatically removed.

Group-level Access

1. Navigate to Users & Groups > Groups

2. Select the appropriate group

3. Select the VPN tab

4. Check the appropriate VPN option

5. Click on update to save your settings

   

User-level Access

1. Navigate to Users & Groups > Users.

2. Select the appropriate user by clicking on the username.

3. Click on the VPN tab.

4. If access to the VPN service is already allowed in the user’s group, select use group configuration. If not, set the option to on to overrule the group configuration.

5. Update your configuration.

   

Users and groups which are synchronized with the SSL Web Portal can be viewed on the Accounts and Groups screens in the Management Console.

User Authentication Policy

Able recommends using DIGIPASS devices for authentication, as this is the most secure option. For instructions on how to assign DIGIPASS tokens to users and additional information about authentication, see the AXS Guard Authentication How To, which is available via the permanently on-screen Documentation button.

1. Navigate to Authentication > Services.

2. Click on SSL Web Portal.

3. Click on Select and choose an Authentication Policy from the list, e.g. DIGIPASSAndPassword, if you want users to authenticate with a one-time password.

4. Update your configuration.

   

Field	Description
Service	The AXS Guard service to be configured. This field cannot be edited.
Authentication Policy	The authentication policy determines how users must authenticate to access the service. Go to Authentication > Advanced > Policy for an overview of policies configured on your system.
Brute Force Attack Protection	Enable to protect the selected service against brute force attacks as configured under Authentication > General.

SSL Web Portal Navigation and Configuration

Before you Start

The underlying SSL Web Portal database does not support:

• the updating of user accounts or credentials via the SSL Web Portal UI.

• the creation or removal of groups via the SSL Web Portal UI.

These actions must be performed via the AXS Guard administration tool.

Client Requirements

Clients require a JRE (version 1.7.0_11 or later). If not, the SSL VPN interface will not function properly. The latest JAVA Runtime environment (JAVA JRE) can be downloaded from: http://www.java.com/getjava/

Logging in to the SSL Web Portal

1. Start your browser.

2. Enter https followed by the external FQDN or IP address of the AXS Guard in the browser’s address bar, e.g. https://sslportal.yourdomain.com and press enter.

3. When prompted, enter your credentials.

Info

By default, the SSL Web Portal listens for incoming connections on port 443. If you specify another port, for instance 4443, users will have to append that port number to the URL (see step 2 above), e.g. https://sslportal.yourdomain.com:4443

Consoles

The SSL Web Portal provides two consoles:

• the management console, which is only accessible to administrators.

• the user console, which is accessible to users and administrators.

After logging in, the user console is displayed by default. Administrators can switch to the management console by clicking on the icon as shown below. This is useful to verify configuration settings from a user’s perspective.

The Management Console

Overview

When an administrator accesses the management console, the extension store is displayed by default (see image below). A menu is available on the left to access other functionalities.

In this section, we explain how to configure user access to different SSL Web Portal resources. This requires the administrator to do the following via the SSL Web Portal Management Console:

1. Installing the extension or plug-in for the required resource.

2. Creating attributes (variables) which can be used to configure resources.

3. Configuring the resource appropriately.

4. Assigning access rights for the resource to users and groups via one or more policies.

Extension Store

Overview

The SSL Web Portal functionally can be extended using plug-ins, called ‘extensions’. Extensions allow SSL Web Portal Administrators to install new or upgrade existing Resources, using the Extension Store.

• The Extension Store is presented when the Management Console is first accessed, and has two purposes:

  1. to install plug-ins and make Resources available for configuration.

  2. to install updates for Resources.

• There are several categories of Extensions, listed on separate tab pages (see image below):

  • Installed: some Resource plug-ins are installed by default

  • Beta: beta Resources are experimental

  • Remote access

  • Others

Installing a plug-in/extension

1. Navigate to Configuration > Extension Manager.

   

2. Click on the appropriate tab for the Resource for which you want the plug-in to be installed, e.g. Remote Access (as shown below).

   

3. Click on Install the extension (see image above). After installation, the Resource will be listed under the Installed tab (see below).

   

Updating a plug-in/extension

1. Navigate to Configuration > Extension Manager and click on the Updatable tab (shown below).

2. The AXS Guard checks regularly for updates. Available updates are listed on this screen. Updates can be selected and the update implemented.

3. To refresh the list of updates, click on Refresh Extension Store (see image below).

4. Click on the Update icon to install a specific update.

   

Info

Some core plug-ins are also available to support the SSL Web Portal framework, e.g. the Agent. These plug-ins can also be updated.

Managing Attributes

Overview

Attributes are variables which can be defined at the policy or the user level. Values assigned by the administrator at the policy level can be overruled by values set by users. Administrators can also set default values, which can be used if a user has not set a user-specific value.

In the rest of this section, we explain how to create attributes in the management console and how to use them in resources. Values of user attributes can also be entered in the user console.

Creating and Modifying Attributes

1. Navigate to Configuration > Attributes. A list of Attribute definitions is displayed.

2. Click on Create Attribute.

   

3. Enter a name and description for the Attribute, e.g. ADpassword and select User Attribute from the drop down menu.

   

4. Choose the appropriate settings to define the Attribute:

   • the most common visibility setting is User or admin may use, view and override

   • the Label is used in the User view to indicate the purpose of this Attribute.

   • the Default Value is used if no User specific value has been configured. This is needed for Attributes which are used to access Resources (e.g. a URL). Otherwise a Resource will not work for Users who have not configured specific values. A value is not needed for the Password Attribute: the Resource prompts for a Password if no value is available.

   

5. Click on Next to continue. A summary for the Attribute definition is displayed.

   

6. Click on Finish to continue and on Exit to exit the wizard.

Using Attributes to Configure Resources

Once an Attribute has been created and its value defined, it can be used while configuring Resources, in any field which shows the special symbol ${} (see image below).

To configure a User Attribute in a Resource:

1. Click on the ${} option (see image below). A pop-up displays the available Attributes.

2. Select the required Attribute.

3. Click on Next to continue with the configuration.

Field values can be entirely variable, or partly constant and partly variable, or can be partly a session value and partly variable.

Example: Using Attributes

• Password: once the Administrator has created an Attribute called Password, end users need to input the value.

• Session password: this Attribute retrieves the password for the current session and enters this value into the password field for the Resource being accessed.

• Mydomain\UserAttribute: where Mydomain is specified as a constant and the UserAttribute part defined by the User.

Creating SSL Web Portal Resources

Overview

Resources are functionalities that are supported by the SSL Web Portal and that can be managed by administrators in the management console. For more information on the concept of resources.

To view, edit, or delete a Resource in the Management Console:

1. Navigate to Resources > Resource type. A list of the existing Resources of the specified type is presented (e.g. the Web forwards; see below).

   

2. To edit, or remove a Resource, click on the Edit or Remove icon respectively in the Resource’s row (shown above).

3. To create a new Resource, click on the Create link (see above, top right).

Info

Clicking on the special symbol ${} displays a drop down menu of the available Attributes which can be used to configure Resources.

OWA 2007 Path-based Reverse Proxy with SSO

This setup only works if the SSL Web Portal uses TCP port 443. See Troubleshooting for information about using a different port.

In this example, we configure a path-based reverse proxy towards an organization’s Outlook Web Access (OWA) 2007 server, using form-based authentication and single sign-on. When the resource is configured, users will be able to access their OWA e-mails simply by clicking on the resource icon. The OWA password is stored in a user attribute.

In this example, we assume the following:

• The public IP address of your appliance is 10.132.27.26

• The secure network range of your appliance is defined as 192.168.0.0/16

• The SSL Web Portal uses TCP port 443 (standard HTTPS)

• 192.168.22.11 is the IP address of the OWA 2007 back-end

• The usernames of the SSL Web Portal and the OWA back-end server are identical

Creating the Password Attribute for SSO

1. Log in to the SSL Web Portal as an administrator.

2. Switch to the management console.

3. Under Actions, click on create attribute

   

4. Enter a name, e.g. owapassword and description for the new attribute.

5. Set the class to User Attribute and click Next.

   

6. Set the type to password.

7. Set the visibility to user or admin. may use, view and override. This is important, since users must be able to update this value when they log in to the SSL Web Portal to access their e-mail.

8. Enter a label.

9. Enter a default value, e.g. password.

10. Click Next and proceed until you are prompted to exit the wizard.

    

Creating the OWA Web Forward

1. Navigate to Resources > Web Forwards and click on Create Web Forward. This initiates the Web Forward wizard.

   

2. Select Create Path-based reverse proxy and click Next to continue.

   

3. Add a name and description for the Outlook Web Access Web Forward, check the add to favorites option and click on Next to continue.

   

4. Enter the the following information:

   • The destination URL of your Outlook Web Access 2007 server, e.g. https://192.168.22.11/owa/auth/owaauth.dll.

   • The allowed paths, i.e. /owa (use the add button for each path).

   • Use the default encoding.

5. Click Next to continue.

   

6. The following authentication types are available:

   • None: authentication is not integrated with the SSL Web Portal and the back-end server requests credentials. If, for example, you do not want to configure single sign-on, selecting None means that the back-end server will request authentication credentials.

   • Form-based: the username and password are requested within a page and authentication is integrated with the SSL Web Portal (single sign-on).

   • HTTP: basic authentication in which a pop-up requests the username and password and authentication is integrated with the SSL Web Portal (single sign-on).

Important

The form type JavaScript (form-based authentication) is not supported.

Enter the following information in the Web Forward Authentication Details screen and click Next when finished:

• Authentication Type: Form-based

• Form Type: POST

• Form Parameters: you will have to manually add the destination parameter and modify the OWA password attribute as follows:

  1. destination=https://ip_of_web_portal/owa. Based on our example, you would need to enter destination=https://10.132.27.26/owa, since 10.132.27.26 is the public IP address of the AXS Guard appliance.

  2. Select the password attribute created earlier and modify it as follows: password=${userAttributes:owapassword}

  3. Select username=${session:username}. This parameter does not need to be modified.

  

• In the Web Forward Policy Selection screen, select Everyone, add and click Next.

  

Testing the OWA 2007 Web Forward

1. Log in to the SSL Web Portal as a regular user. Note that the username to log in to the SSL Web Portal must match the username that is known by the OWA 2007 server.

2. Click on attributes and update the OWA password.

   

3. On the dashboard, click on the OWA resource icon (under "My Favorites"). You should be logged in without having to enter extra credentials for the OWA 2007 back-end. Make sure to allow pop-ups for the OWA back-end.

   

Intranet Server Replacement Proxy with HTTP-based Authentication

In this example configures a replacement proxy towards an organization’s Intranet, with HTTP-based authentication.

1. Navigate to Resources > Web Forwards and click on Create Web Forward (see below).

   

2. Select Create Replacement proxy (see below) and click on Next to continue.

   

3. Add a name and description for the Intranet Web Forward (see below) and click on Next to continue.

   

4. Add the paths and URL pointing to your Intranet server as shown below. Click on Next to continue.

   

5. For Authentication Type (see screen below), there are three options:

   • None: authentication is not integrated with the SSL Web Portal, and the back-end server requests credentials. If, for example, you do not want to configure Single Sign On, selecting None means that the back-end server will request authentication credentials.

   • Form-based: the User name and password are requested within a page and authentication is integrated with the SSL Web Portal authentication. For an example of form-based configuration, please see OWA 2007 Path-based Reverse Proxy with SSO).

   • HTTP: basic authentication in which a pop-up requests the User name and password (see example below) and authentication is integrated with the SSL Web Portal authentication (Single Sign On).

     Important

     The form type JavaScript (form-based authentication) is not supported. Select the HTTP option for this example.

     

6. For Preferred Scheme please refer to the documentation of your back-end server.

7. In this example, we use:

   • the User name from the SSL Web Portal session

   • the password from the SSL Web Portal session

   These session Attributes are created automatically in the SSL Web Portal. To configure Single Sign On for the Web-based application, click on the special symbol ${} next to the User name and Password fields, to select from the menu of available Attributes. Select the session attributes for the User name and Password fields.

   Important

   If DIGIPASS authentication is used for the SSL web portal login, as recommended by Able, this will not work, as it is interpreted as a replay attack (hacking attempt). It is therefore recommended to create a user attribute.

   

8. Assign the newly created Resource to Users and/or Groups by adding the correct SSL Web Portal Policy. Click on Next to continue.

   

9. A summary is presented. Click on Finish to continue, and on Exit to exit the wizard.

   

Network Places

This example configures a Network Place towards an organization’s file share. In Step 2 Network Place Path Details of the Create Network Place wizard, it is possible to use pre-configured User Attributes.

1. Navigate to Resources > Network Places.

2. Click on Create Network Place (see below).

   

3. Click on Create Network Place (see below).

   

4. Select the Automatic type (see image below).

5. Enter the path towards your network share and choose the correct permissions on this share. SSL Web will auto detect the type of the Network Place based on the entered path. (In this example a Windows Network is detected.) Click on Next to continue.

   

6. Leave the user and password fields empty (see image below), to be entered manually when the network place is being accessed. (User attributes can also be used to configure Single Sign On). Click on Next to continue.

   

7. Assign the newly created Resource to Users and/or Groups by adding the correct SSL Web Portal Policy (see image below). Click on Next to continue.

   

8. A summary is presented. Click on Finish to continue, and on Exit to exit the wizard.

   

Application: Wake-on-LAN

Wake-on-LAN, commonly abbreviated as WOL, is an application which allows a dormant PC in your secure LAN to be activated and used remotely. Its functionality is dependent on:

• The Wake-on-LAN functionality being present and enabled on the PC

• Your network infrastructure being able to support and allow the transmission of wake-up packets (for example over network switches and firewalls)

Please consult your PC and network hardware documentation for further guidance on these dependencies.

The Wake-on-LAN plug-in can be installed in the Extension Store. The application then needs to be created to be available to SSL Web Portal Users.

In Step 3 Application Options of the Create Application wizard, it is possible to use pre-configured User Attributes.

Creating the Application

1. Navigate to Resources > Applications.

2. Click on Create Application Shortcut (see below).

   

3. The number of applications shown (see below) varies depending on the installed extensions. Select Wake-on-LAN Client for aXsGUARD (see below) and click on Next to continue.

   

4. Add a name and description for the Wake-on-LAN application (see image below), and click on Next to continue.

   

5. On the Application Options screen (see below) enter:

   • the MAC Address of the PC to which the Wake-on-LAN connection needs to be made

   • (optionally) the Password for the connection

   • the aXsGUARD Gatekeeper interface: this is the network device to which the PC to wake up is attached

   • the Broadcast checkbox: this sends a wake-up call using an Ethernet broadcast frame rather than an Ethernet frame for the PC alone.

   

6. Assign the newly created application to Users and/or Groups by selecting the appropriate Policy (see below and Managing SSL Web Portal Policies). Click Next to continue.

   

7. A summary is displayed (see below). Click on Finish to continue, and on Exit to exit the wizard.

   

Application: JAVA RDP client (Remote Desktop)

The Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft, which allows a user to connect to another computer with a graphical interface. Rdesktop is a similar RDP application for Linux clients. Advanced Native RDP (experimental) allows use of local printers and network shares in an RDP session.

In this example, we configure an RDP session towards a server in the secure LAN. The Proper JAVA RDP plug-in can be installed in the Extension Store. The application then needs to be created to be available to SSL Web Portal Users.

In Step 3 Application Options of the Create Application wizard, it is possible to use pre-configured User Attributes.

Creating the Application

1. Navigate to Resources > Applications.

2. Click on Create Application Shortcut (see below) and click on Next.

   

3. The number of applications shown (see image below) varies depending on the installed extensions. Select JAVA RDP client (ProperJAVARDP) and click on Next to continue.

   

4. Add a name and description for the RDP application (see image below), and click on Next to continue.

   

5. On the Application Options screen (see below), enter the Host name of the server to which the RDP connection needs to be created. Default values can be used for the remaining fields. Click on Next to continue.

   

6. Assign the newly created application to Users and/or Groups by selecting the appropriate Policy. Click Next to continue.

   

7. A summary is displayed (see below). Click on Finish to continue, and on Exit to exit the wizard.

   

Application: Citrix Client

• It is possible to make an application available directly in the SSL Web Portal without using the ICA file.

• This setup uses a JAVA based ICA client (JICA) which points directly to a specific Citrix server and application name requiring authentication.

• This setup does not allow load balancing since it bypasses the Citrix XML server and ICA file system. It can be used when an application on a specific Citrix server should be made available through the SSL Web Portal.

• For advice on specific setups requiring load balancing, please contact support@axsguard.com.

This example configures a Citrix client application (versions 3, 4 and 5 are supported) to establish a connection towards a Citrix server in the secure LAN. The Citrix forwarded by aXsGUARD plug-in can be installed in the Extension Store. The application then needs to be created to be available to SSL Web Portal Users.

In Step 3 Application Options of the Create Application wizard, it is possible to use pre-configured User Attributes.

Creating the Application

1. Navigate to Resources > Applications.

2. Click on the Create Application Shortcut (see below).

   

3. The number of applications shown in step 1 of the Create Application wizard (see below) varies depending on the installed extensions. Select Citrix forwarded by aXsGUARD, and click on Next to continue.

   

4. Add a name and description for the Citrix application (see image below), and click on Next to continue.

   

5. On the Application Options screen (see below) enter the:

   • Hostname of the server to which the Citrix client needs to connect.

   • Application name of the Citrix application to be used.

   • Credentials to login to the Citrix server. These cannot be left blank. User Attributes can also be used to configure Single Sign On. Default values can be used for the remaining fields. Click on Next to continue.

   

6. Assign the newly created Resource to Users and/or Groups by selecting the appropriate Policy. Click on Next to continue.

   

7. A summary for the application is displayed (see below). Click on Finish to continue, and on Exit to exit the wizard.

   

Viewing AXS Guard Users and Groups

Users and Groups which have been synchronized in the SSL Web Portal can be viewed in the Management Console.

• Navigate to Access Control > Accounts. A list of the Users displays (see image below).

• Navigate to Access Control > Groups. A list of the Groups displays (see image below).

Managing SSL Web Portal Policies

SSL Web Portal Policies link Principals (Users and or Groups) to the Resources they can use.

Everyone and Administrator Policies are default Policies which automatically include all Users and all Administrators respectively.

Important

Do not configure Administrator rights for Users using the Administrator Policy in the SSL Web Portal, as changes to this Policy are overwritten each time the SSL Web Portal is restarted. Use the AXS Guard Administrator Tool to configure User Administration rights. A User synchronized with the SSL Web Portal, who has Basic, Full or Advanced Administrator rights in the AXS Guard Administrator Tool, automatically has Administrator rights in the SSL Web Portal.

To view, edit or delete SSL Web Portal Policies:

1. Navigate to Access Control > Policies. A list of the existing Policies is presented (see below)

2. Click on the Edit or Delete icon in the Policy’s row to edit or delete it respectively.

   

To add / create a Policy:

1. Navigate to Access Control > Policies.

2. Click on Create Policy (see image below).

   

3. Choose a policy name and add a description (see below). Click on Next to continue.

   

4. Enter User Account and/or Group names (see below).

5. Click Add to add the User Account and/or Group to the policy. Click on Next to continue.

   

6. A summary is presented (see below). Click on Finish to store the new policy and on Exit to exit the wizard.

   

Managing Profiles

Overview

Profiles define session and Agent settings on logon and can be created and modified in the Management Console.

Creating Profiles

1. Navigate to Resources > Profiles and click on Create Profile (see image below).

   

2. Enter the name and description for the Profile (see image bellow) and click on Next.

   

3. Assign the newly created Resource to Users and/or Groups by adding the correct SSL Web Portal Policy (see image below). Click on Next to continue.

   

4. A summary is presented. Click on Finish to continue, and on Exit to exit the wizard.

Modifying Profiles

1. Navigate to Resources > Profiles and click on More and Configure (see image below).

   

2. Two types of settings can be configured (see image below):

   • session settings: here you can set Web server time out, and User Interface preferences, e.g. whether items are displayed as icons or in lists by default.

   • Agent settings: here you can set SSL Web Agent settings, such as whether the Agent starts automatically on logon and proxy server settings, such as the hostname and port.

3. Click on the session or Agent icon to access the fields.

4. Configure settings as appropriate and click on OK to finish.

   

Adding Resources to Favorites

Overview

Favorite Resources are displayed automatically when a User logs in to the SSL Web Portal. A Resource can be defined as a Favorite in one of two ways:

• by the Administrator while creating the Resource.

• by the User.

Favorites defined by Administrators cannot be removed by Users. Users can remove Favorites they have defined themselves.

Administrator Definition of Favorites

When defining the details for a Resource in the Resource creation wizards (e.g. see image below), there is an Add to favorites checkbox. To add the Resource as a Favorite, check the Add to favorites box and click on Next to continue with the wizard.

Checking Add to favorites in the creation wizard means that a desktop icon will be displayed for the Resource in the User Console (see The User Console) for all Users who are attached to the Policy (defined later in the wizard) i.e. for all Users who are permitted to use the Resource.

The User Console

Overview

A default homepage (My Favorites) with favorite Resources is shown when a User accesses the User Console (see image below). Users may:

• launch the Agent

• use available Resources

• manage favorites

• edit attributes

• edit profiles

Using the Agent

The SSL Web Agent is a small JAVA application used by most of the Resources to provide a secure channel between a remote client and the AXS Guard SSL Web Portal. A User Profile can be configured to launch the Agent on login), or the Agent can be launched manually by clicking on the Agent launch icon. The Agent launch icon is indicated in the top right of the image above. Once launched, the Agent icon is minimized in the User system tray (see below).

Resources available to the User can be launched directly from the Agent system tray icon by right clicking (see below).

The Agent cannot launch/install on a client machine if no JAVA runtime environment is present. Most client machines already have a JAVA runtime environment installed.

Using Resources

There are several ways for Users to launch Resources:

• on the My Favorites screen, by clicking on the Resource icon or listed entry for the Resource

• by navigating to Resources > Resource type, and clicking on the icon or listed entry for the Resource

• by right clicking on the minimized Agent icon in the User system tray. Available Resources are listed for selection.

Managing Favorites

1. Select the Resource type of your choice in the left menu and click on the view resources as a list icon (see image below).

   

2. Click on the More link (see image below) and select Add Favorite or Remove as appropriate.

   

Editing Attributes

Attributes are fields or variables created by Administrators for efficient configuration of Resources.

Resources configured with a User-specific Attribute are not accessible to Users until they enter a value for the Attribute (unless a default value has been specified by the Administrator). Users can enter values for available Attributes as explained here.

To edit an Attribute:

1. Navigate to My Account > Attributes and click on the view resources as a list icon.

2. Attributes available for editing are displayed (see below). You can enter values for Attributes on these screens.

3. Click on Save to finish.

   

Using Profiles

Overview

sers can select the default Profile to be assigned on logon, or opt to select one from the available Profiles on logon. We explain this in the following section. For instructions on creating and modifying User Profiles in the Management Console.

Profile Selection

1. Navigate to My Account > Attributes, and click on the Profiles tab (see image below).

2. Choose a default Profile to be assigned on logon, or select to choose a Profile on logon.

3. Click on Save to finish.

   

If you have selected to choose a Profile on logon, you will be offered a menu for selection after successful logon (see image below).

SSL Web Portal Backups

• Able does not back up your SSL Web Portal configuration and user data. Configure your AXS Guard appliance to automatically back up your configuration and user data on a file server in your network.

• The SSL Web Portal service is stopped during backups and is automatically restarted when a backup has been made. It this therefore recommended to schedule your backups outside office hours.

Daily backups of your SSL Web Portal configuration to a network share can be configured via the AXS Guard administrator tool. When a backup has been made, system administrator(s) are notified by e-mail. See the AXS Guard System Administration How To guide for additional information.

1. Navigate to System > Tools > Back-up.

2. Click on the Daily back-up on Network Share tab.

3. Enter the time, remote server and the network share to be used on the remote server.

4. If authentication is required to access the network share, enter the username and password.

5. Select the Backup SSL Web Portal settings option and update your configuration.

Server Setting	Description
Enable automatic backup to server?	Automatically sends a backup of your configuration and user data to the specified server every 24 hours (if enabled). In the unlikely event of a system crash, you will be able to swiftly recover your settings and user data as they were at the time of the last backup. Enabling this option is highly recommended.
Do automatic daily backup at (hh:mm)	Performs a backup at the specified time. Use the hh:mm format.
Remote Server Name	The hostname or IP of your backup server.
Share on Remote Server	The name of the SMB share as broadcasted by the backup server.
Directory on Share (optional)	Specify a directory within the share. Use this if you shared an entire drive, e.g. d:. This prevents backup data from being written to the root directory of the shared drive. Use \\ for subfolders, e.g. backups\\axsbackup is valid syntax.
User	The username to log in to the backup server.
Password	The password to log in to the backup server.
Backup Contents	Select the data to be included in the backup.

SSL Web Portal Log Files

Two types of SSL Web logs are recorded and can be viewed in the AXS Guard Administrator Tool:

• SSL_Web_Portal.log: general information about the SSL Web Portal installation.

• Date.request.log: all service requests received on a particular date.

To access the logs:

1. Navigate to VPN > SSL Web Portal > Logs.

2. Select the appropriate log file.

   

Troubleshooting

No connection to the SSL Web Portal

Check that you are not being blocked by the firewall. Enter your IP address as a search string in the AXS Guard Administrator Tool logs (Firewall > Logs, choose today) to verify this.

Access denied when clicking on Access Portal (Proxy restriction)

If you try to connect to the SSL Web Portal running on a non-standard port (i.e. other than 443), your connection may be dropped by the AXS Guard proxy. The AXS Guard proxy is configured to only allow a certain range of ports. To solve this problem, add the configured SSL Web Portal port to the range of permitted ports in the Administrator Tool under Web Access > Server > Safe proxy ports.

The SSL Web Portal Agent doesn’t start

The Agent needs a JAVA Runtime environment (JRE version 1.7.0_11 or later). The latest JRE can be downloaded from: http://www.java.com/getjava

Web Forward doesn’t work (pop-up blocker)

Check if the Web Forward isn’t blocked by a pop-up blocker. If so, whitelist the URL and try again.

A Resource configuration with attributes doesn’t work for certain users

A Resource configured with an Attribute only works for users with filled-in Attributes, unless a default value is specified for this Attribute.

OWA path-based reverse proxy Web Forward and SSL Web Portal not on port 443

This setup does not work due to an erroneous redirect in Outlook Web Access (OWA). Configure OWA to run on the custom port to solve this problem. Running OWA on the same port in the LAN resolves this issue.

Installation not possible, because port 443 already in use

If an error message displays after configuring the Web Server and clicking on Next, a service is already running on port 443. You need to:

1. Disable any services, which are not required, e.g. Webmail reverse proxy configurations and Open VPN solutions.

2. Configure the other service on another port, if possible, or use a second IP address.

3. Configure the SSL Web Portal on another port (not recommended).

Support

If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

1. Check the troubleshooting section of the feature-specific manual.

2. Check the knowledge base on this site for information about special configurations.

3. If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400
support@axsguard.com