Awingu

Getting Started Guide

Version 5.5

1
1. Introduction and assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Set up your network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Install Awingu appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Prepare your Windows back end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. The Awingu Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Connect Awingu to your Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Enabling SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Multi Factor Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Publish apps and desktops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Publish drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Customize the branding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2
 Introduction and assumptions
This document is a summary of all the steps that are needed to setup a single-node, single-tenant Awingu appliance and integrate it into an
existing Windows infrastructure. For more details or complex setups, please consult the Awingu Administration guide

Next to this getting started guide there is also a set of short 3-5 minute instruction videos available to help you with the installation and
configuration of Awingu. We recommend using these videos in combination with this getting started guide. Videos can be found via this link https:/
/awingu.com/technicalvideos or by searching on YouTube.

What is Awingu?

Awingu is a (virtual) appliance that acts as a gateway and allows secure connections from any modern (HTML5) browser to existing company
resources such as:

Windows applications (via RDP)

Windows and Linux full desktops (via RDP)
File servers (via CIFS/WebDAV)
Intranet Web based applications (via reverse proxy)
SaaS applications

On top of this, Awingu adds an extra layer of security (MFA, audit, encryption, recording, ...) and collaboration (file and session sharing).

Awingu itself is not a SaaS service and needs to be installed and integrated into your own infrastructure. Awingu is distributed as a virtual
appliance. There are images available for most of the on-site and cloud-based infrastructures. Next to this Awingu is multi-tenant which means
that a single Awingu instance can be used for multiple customers each with their own branding, Windows back end and configuration. Awingu
enables you to create your own SaaS offering for your clients, while keeping full control over the complete solution.

Awingu Architecture

There are 3 layers in the Awingu Architecture:

The client layer which can be any web browser on any device on any operating system that supports HTML5 web sockets. This means that
almost every modern browser should work.
The Awingu layer: this can be one or more Awingu virtual appliances.
An existing Windows-based back end: Microsoft Windows AD (or LDAP) for user authentication, in case applications are published on a
Microsoft terminal server and in case files are published on a SMB server.

The 3 layers are also completely isolated from each other and both the client and the back-end layer do not require any additional software
installation. All connections from the client layer to the Awingu layer are made using http/https. Connections from the Awingu layer to the
Windows back-end layer use standard protocols like LDAP, RDP, CIFS. More details on the different network flows can be found in the "install
the appliance and setup your network" chapter of this guide.

The Awingu (virtual) appliance is available for both

On-premises installations (Hyper-V, VMware ESXi, KVM, OpenStack, .... )

Cloud installations (Azure, Amazon, Google, IBM).

Copyright © 2012-2023, Awingu 3

 The Awingu appliance can be downloaded from https://download.awingu.com . We recommend to always download and install the latest
version.

Awingu can be installed and configured without a license. All functionality will work and up to two concurrent users will be able to log in to
Awingu. This allows you to test and set up without a license. Once you go into production, an Awingu license needs to be bought.

Assumptions

For this guide, we assume there is already an existing Windows infrastructure which includes:

A Windows Active Directory (No Azure AD Only setup)

Windows applications servers (RDS / Terminal Servers) or VDIs (accessible via RDP)
File server supporting CIFS/SMB access

If this is not yet present, Awingu offers some guides on the support portal that explain how to setup these Windows components.

More details on this Windows back end can be found in the "prepare your Windows back end" chapter.

For this getting started manual, we assume this scenario:

Only a single Awingu instance. Awingu can be configured in a "clustered" setup for purposes such as scaling-out or high availability. Details
on scaling out Awingu can be found in the Awingu Administration guide
Only one Windows back-end. Awingu can be configured with multiple tenants and each tenant can also connect to a different Windows back
end. Details on multi-tenancy can be found in the Awingu Administration guide

Copyright © 2012-2023, Awingu 4

 Set up your network
Before we start the installation, it is important to understand how the Awingu appliance can be integrated into the existing network.

As the Awingu appliance doesn't require any agents or browser plug-ins on the clients and only relies on standard protocol access (so also no
agents or additional software) to the back end, it can be easily installed into existing networks. Existing security equipment like firewalls, load
balancers, SSL offloaders / reverse proxies can be reused.

Also this architecture allows the 3 layers (clients, Awingu and the Windows back end) to be upgraded independently from each other.

Important: the Awingu appliance expects incoming traffic on port 80 (HTTP) or 443 (HTTPS).
From the outside world, you can however make Awingu accessible on a different port if you rely on e.g. a firewall or reverse proxy server
to properly forward the incoming traffic to the correct ports.

In this getting started manual we will describe 3 possible network scenarios. For more advanced network setups, please have a look at the full
admin guide.

1. Awingu behind a simple port-forwarding firewall

2. Awingu behind a reverse proxy / load balancer that does SSL offloading
3. Awingu in a DMZ network

Awingu behind a simple port-forwarding firewall

This is the most simple scenario to deploy Awingu. From the firewall port 80 and/or 443 are forwarded to Awingu which is in the same network as
the company resources (AD, RDS, web server and/or file server). SSL offloading can be enabled on the Awingu appliance by using the built-in
Awingu SSL offloader.

Awingu supports 2 methods for SSL offloading: for this scenario to work, you need to simply forward the incoming HTTPS traffic (TCP port 443)
to Awingu. Awingu can do the SSL offloading on the appliance.

Using standard certificates. In this case you need a certificate in the CRT / KEY format. Check the support portal on how to convert for
example pfx certificates to CRT / KEY format
By using the free public Let's Encrypt service that generates certificates. By providing the external DNS name to Awingu, the certificates are
automatically requested and renewed every three months. To use Let's Encrypt, also incoming HTTP-traffic (port 80) needs to be allowed.

For this setup to work there are 3 requirements:

1. Port 443 (HTTPS traffic) on the public IP address needs to be forwarded to Awingu. This assumes that no other service is already
using this port. If this is the case, an additional public IP address needs to be added to the firewall.
2. This setup can only be used for single node Awingu setups. When using multiple nodes, you need to setup a load balancer /
reverse proxy in front of Awingu (see next design)
3. A certificate is required in CRT/KEY format. In case you don't have a certificate, Awingu allows you to automatically create
certificates via the free Let's Encrypt service. In that case also port 80 (HTTP) needs to be forwarded to the appliance.

Awingu behind a reverse proxy / load balancer that does SSL offloading

Copyright © 2012-2023, Awingu 5

 In this scenario there is an existing reverse proxy / load balancer / SSL offloader. On that device there is a virtual host defined that forwards all
traffic linked to a specific DNS record / host header to one or more Awingu appliances. In this scenario we also assume the reverse proxy / load
balancer / SSL-offloader also takes care of the SSL offloading.

In this scenario Awingu is not directly accessible from the outside world and the reverse proxy / load balancer / SSL offloader will terminate the
incoming traffic first and then proxy it to the Awingu appliance. The main advantages are:

You can have multiple services that use HTTPS traffic on the same IP address
In case the device is capable of doing load balancing: you can also use it in combination with a multi-node Awingu.

Configure the reverse proxy / load balancer / SSL offloader correctly so it doesn't break the HTML5 web socket Awingu uses.
Make sure the header information is preserved, so that Awingu knows what the original IP addresses were rather than always getting the
IP address of the reverse proxy / load balancer / SSL offloader.

The admin manual contains all details and also on the support portal you can find some specifics for some vendor specific solutions like F5,
Netscaler, Nginx, ...

In most cases, these headers need to be set correctly on the device:

Header Value Status

Connection This value should be equal to "Upgrade" Mandatory for getting web sockets to work

Upgrade Should be equal to websocket in case of a websocket upgrade Mandatory for getting web sockets to work

X-Forwarded-Proto This value should be equal to "https" Mandatory for getting web sockets to work

X-Real-IP This should be the IP address of the requesting client Recommended for security

X-Forwarded-For This should be the IP address of the requesting client Recommended for having correct auditing

X-Forwarded-Host This is the FQDN of the server name that was requested by the Recommended for having correct auditing
client

Host This is the FQDN of the server name that was requested by the client Recommended for having correct auditing

Awingu in a DMZ network

As Awingu only uses standard protocols and ports, it can easily be installed in a DMZ network.

Both scenarios (port forwarding or reverse proxy) can be used to access the Awingu environment from the public network. In this chapter we
describe all other network flows that are needed to get Awingu installed and working from in a DMZ or firewalled network:

Copyright © 2012-2023, Awingu 6

 User authentication
Accessing resources like Windows apps, storage, VDIs & web apps
Installation and other needed network traffic

When using a multi-node Awingu, it is important that all nodes can freely communicate with each other. So all Awingu nodes of a multi-
node cluster need to be in the same network with no firewalls between the individual nodes.

User Authentication network flows

Awingu uses LDAP or LDAPS (recommended) to communicate with the AD or LDAP server. This communication is used to validate the user
credentials and also fetch the security groups of the user. When password changes via Awingu are allowed, also Kerberos communication is
needed and it's mandatory to use LDAPS (TCP 636). Doing password changes via LDAP (TCP 389) communication will not work.

Communication Fr To Information
om

LDAP: TCP port 389 Awi All AD or LDAP servers in

ngu the configuration

LDAPS: TCP port 636 Awi All AD or LDAP servers in Only required when users need to be able to change their password.
ngu the configuration
Also requires certificates on the AD / LDAP server.

Kerberos: UDP port 88 Awi Kerberos server Only required when users need to be able to change their password at next logon.
and TCP port 88 ngu
The Kerberos server should also have PTR (reverse DNS) and SRV records in place to
locate the KDC server and define the protocol to use.

RADIUS: UDP port 1812 Awi RADIUS server Only required when using an external, RADIUS-based, MFA server
ngu
Awingu also offers the possibility to integrate natively with some third party MFA providers
like Duo, SMSpasscode,... .
More details on network flows can be found in the admin manual.

Application and Storage network flows

Awingu uses RDP to connect to Windows-based applications and desktops. Besides network access, no other access is needed. In case a
Microsoft RDS broker is used, Awingu needs RDP access to both the broker as well as to all individual session hosts that are configured behind
the broker.

Storage can be accessed through CIFS and WebDAV.

Awingu can also publish web-based applications. In case the websites are external to the organization, the browser will open them directly. This
traffic will not pass through Awingu.

It is also possible to access internal websites. Awingu will act as a reverse proxy and needs to be able to access the internal website.

Copyright © 2012-2023, Awingu 7

 Communication Fr To Information
om

RDP: TCP port 3389 Awi Session hosts, VDI hosts and
ngu RDS brokers

CIFS: TCP port 445 Awi All storage servers. Only needed when offering Awingu Drives via CIFS
ngu

WebDAV: TCP port Awi All storage servers Only needed when offering Awingu Drives via WebDAV
80/443 ngu

HTTP/HTTPS: TCP Awi Web servers Only needed for internal web apps published through the reverse proxy feature.
port 80/443 ngu
In case the internal website does not run on standard ports 80 or 443, this non-standard port
needs to be added to the firewall rules.

Other network flows

During the Awingu installation, we need to configure NTP, DNS and database access. The installation web interface is reachable on port 8080.
After the installation has finished, this port is no longer needed.

In most simple cases the AD also acts as the DNS and NTP server, but Awingu supports also more complex setups with different DNS servers
per tenant.

To do this there are 2 levels of DNS:

DNS servers can be configured on the global appliance level. These servers are configured during the installation.
Each tenant can also be configured with optional DNS servers. These servers are configured when adding a tenant.

The optional DNS servers (per tenant) are used to resolve the host names of the servers specified in the tenant's application server or drives
section. These can be different servers per tenant. So there is no need to have a global DNS service spanning all individual tenants.

The global DNS servers are used if there is no tenant specific DNS configuration or for the resolution of names linked to the appliance (for
example proxy server, Awingu update server, ...)

Communi Fr To Information
cation om

Installer: Inst Awingu Only needed once during the first time installation. Firewall rule can be removed after the installer has finished
TCP port all
8080 PC

NTP: UDP Awi NTP Mandatory.

port 123 ngu servers
Awingu needs to connect to a time server to make sure clocks get synchronized. In most cases the AD also can function as a
NTP server. If no internal NTP server is available, a public one like pool.ntp.org can be used.

DNS: UDP Awi All DNS Mandatory.

port 53 ngu servers.
Awingu needs to do name resolution of all the servers specified in the configuration. So both the global DNS servers as the
optional DNS servers specified in the tenants need to be reachable from the Awingu appliance.

When using an external database which is not in the DMZ network, also make sure all nodes have access to the database!

Copyright © 2012-2023, Awingu 8

 Install Awingu appliance
The Awingu appliance is available for on-premises installations or cloud installations. In this getting started guide we guide you through the
installation of a single node Awingu. Please note that Awingu can also scale out vertically by adding more nodes to the Awingu cluster. Details on
multi-node deployments are described in the admin manual.

There is no difference in features and functionality between running Awingu on-premises or in the cloud. Only the way to get and install the image
is different and will be shortly discussed in this chapter. Once the image is deployed, all the configuration is exactly the same.

Awingu Sizing Requirements:

Minimum sizing is 2 CPU, 4 GB RAM and 80 GB hard disk.

Warning: 3.7 GB which is suggested on some public clouds is not sufficient!

When adding extra resources such as CPU and memory to an appliance, Awingu will be able to handle more RDP streams and file operations.

In general we recommend that as of 300 concurrent RDP streams it is better to look at a multi node setup. For more details on sizing and multi
node setups, please have a look at our Awingu Administration guide for more details.

For deployment on private clouds / on-premises infrastructure:

The Awingu image can be downloaded from https://download.awingu.com/

From here the appliance images for most hypervisor technologies can be downloaded.
Refer to the admin guide of the specified version to check which hypervisors and cloud platforms are supported.

Please always download the 'latest' version if you start a fresh installation. The older versions are made available for users that would like to
extend their existing Awingu cluster with additional nodes.

Our admin guide contains details on how to import the different images on the different hypervisors. Once the image has been booted, it will
broadcast a DHCP request and it will honor the received IP information. You will also be able to access the console to change the IP address to a
static address. After the IP has been correctly set, you will be able to go through a web-based installation wizard.

Deployments on public clouds

Azure Cloud

Copyright © 2012-2023, Awingu 9

 On Azure the image can be deployed from the Azure market place. You can simply add a new resource and search for Awingu to find the
appliance in the marketplace. When you search for Awingu you will find 2 solutions in the Azure catalog:

Awingu: the standard Awingu appliance, similar to the images you can download for on-premises. Installation still needs to be done and you
need an existing Windows back-end to connect with.
Awingu All-In-One: a template that not only installs an Awingu image, but also creates a new AD server and at least one terminal server. Also
all configuration and installation of the Awingu and Windows back end is done automatically so that at the end of the installation you have a
fully working green-field setup available.

Amazon Web Service (AWS)

Images for Amazon Web Service subscription can be readily deployed via the links provided on https://download.awingu.com

Google Cloud Platform

Navigate to https://repo-pub.awingu.com/appliances/latest/gce/ in your web browser and download the most recent .tar.gz file.

You can import this image file into your Google Cloud Platform by following Google's official instructions. https://cloud.google.com/compute/docs
/import/import-existing-image

After importing the image, create a new VM instance using this image.

Copyright © 2012-2023, Awingu 10

 Prepare your Windows back end
We assume in this getting started manual that there is already an existing Windows back end available. If this is not the case, please create this
first or use the Awingu All-In-One solution on Azure to deploy and create everything for you.

Active Directory

Awingu doesn't have any built-in user database and falls back to AD or an external IDP for this. If users should be able to change their
passwords through Awingu, the AD server needs to be equipped with a certificate and configured to use this. In this guide we will describe how a
standard login using AD needs to be set up. For more complex scenarios like Single Sign-On with an external IDP such as Azure, ADFS, Google,
... please have a look at the admin guide in the section on setting up SSO.

Awingu doesn't require any specific functional AD level. Although to make some features work, such as auto-import from AD, we recommend to
use a modern Windows Server version. If the version is too low, some features may not work as expected.

Awingu is not compatible with Azure AD. When using Azure AD for Single Sign-On (SSO), a real AD is still needed to join the application
servers into the domain and to fetch the security groups.

In case there is no local AD the only solution is to install the Azure AD Directory Services feature (AADDS) and link the application
servers and Awingu to these Azure AD DS servers.

To enable the auto-import of resources we need a bind user and password. This should be a normal, non-admin account that doesn't need any
privileges except that the password should not expire. No write access to the Active Directory is necessary. During the authentication in Awingu,
the user credentials provided will be used to do an LDAP or LDAPS bind with the AD server. If successful, Awingu will get a list of all groups the
user is member of.

Also it is recommended to put all users that need to become an Awingu admin (= have privileges to make changes to the Awingu configuration)
into a dedicated security group.

Group Policies

There are a few group policies which are required for a correct end-user experience.

These are the following:

Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session
Host / Connections
Restrict Remote Desktop Services users to a single Remote Desktop Services sessions: Disable. (see remark bellow)
Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop
Sessions Host/Session Time Limits:
Set time limit for disconnected sessions: End a disconnected session in 1 minutes
Set time limit for log off of RemoteApp sessions: RemoteApp session log off delay: Immediately
Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session
Host / Connections
Allow remote start of unlisted programs: enabled

By enabling the "session merge" option in the app publication, different apps can be merged into existing remote app sessions. This avoids that
for each app a new RDP stream needs to be started resulting in loading GPOs and profiles each time.

Copyright © 2012-2023, Awingu 11

 Next to the required GPOs for a correct functional working, there are also a couple of the GPOs that we have gathered within the Awingu
Administration guide to restrict the security settings within a remote desktop session.

When using User Profile Disks or FSLogix Profiles make sure all apps from the same collection are session merged in Awingu

Microsoft Application Server (RDS)

When Windows applications should be delivered, we require the setup of a remote desktop session host (RDSH) on the Microsoft Windows back
end. Awingu can integrate with Windows Server. Windows applications on the back end can be published as a RemoteApp or by starting an
application within an RDP session. Delivering applications via RemoteApp is the recommended approach.

Applications that need to be delivered should be installed on the application servers and operate within a multi-user context. When using the
RemoteApp protocols, the application can be directly published (as RemoteApp) from the Server Manager. Please refer to the Awingu
Administration manual for detailed description on how to publish RemoteApps.

Awingu supports connections directly to a session host as well as making connections to an RDS broker.

VDI / Full desktops

Awingu can also connect to full desktops using RDP. When using a Windows OS without the RDS session host role installed, the sessions will be
limited to 1 user per server/client.

Awingu is also compatible with Azure Virtual Desktop. in that case multiple users can connect to the same Windows virtual machine.

Mind that the users have to be added explicitly to the allowed remote access users on the Windows client OS. By default only domain admins are
allowed to do this.

Files Service Integration

The Awingu appliance can integrate with existing file servers. For Windows file shares, it is important that those file shares are part of the same
domain as to which Awingu is configured. All access to the files will be with the identity of the user.

Copyright © 2012-2023, Awingu 12

 The Awingu Installer
Once the Awingu appliance has been deployed on-premises or in the cloud, the first thing that needs to happen is to run the Awingu installer.
During the installation the Awingu appliance will initiate and setup all services.

Use a web browser to go to http://<IP Address of your appliance>:8080/ to begin the installation wizard.

EULA

If deployment was successful, you should see the EULA.

Please read the EULA and then check the "Yes, I have read and hereby accept the above license terms and conditions" to proceed.

Restore Backup (optional)

It is possible to restore the Awingu environment from an existing backup. Mind that you must use the same Awingu version and same type of
database.
Other settings such as IPs, hostnames, credentials, ... will be prefilled, but can be altered.

For more information about backups, see Backup and recovery of the Awingu Environment .

For new installations, you can simply skip this step.

Copyright © 2012-2023, Awingu 13

 Management User

Next step is to setup an Awingu Management User.

This user can't be changed and should not exist in your AD domain. The password can be changed later on.

This Management User will be able to login at any time and alter configuration settings. This management user will not be able to launch
streamed applications or access drives. This user is not taken into account for licensing and does not require a one-time-password (OTP) to sign-
in. It is advised not to use this Management User, other than for the initial install or in case of emergency.

The user is automatically logged out after 15 minutes!

DNS and NTP

Next we need the IP address(es) of the DNS and NTP servers. In general we recommend to use the AD servers as DNS servers so they can
also resolve the internal names of the application servers used.

Host name can not be changed afterwards. When planning a multi node deployment, it's recommended to immediately set the host name to a
meaningful name.

Databases

This will give you the option to use the built-in database or use an external database. External databases are needed when you set up a multi-
node deployment of Awingu. Multi-node deployments are needed for 100+ concurrent user setups or for setups that require high availability. Mind
that you can't switch afterwards from an internal to an external database without reinstalling everything. Details on the connection strings and
supported versions for an external database can be found in the admin manual. For this manual we assume a single node Awingu deployment
with built-in database.

Summary

The summary of the configuration appears. After clicking [Finish], the installation will start. Please take into account that depending on the type of
storage used and the overall performance of the system this installation can take between 10 to 30 minutes.

If installation is successful, the installation wizard will disappear and a login prompt will be presented. The install service on port 8080 will
also no longer be accessible.

Copyright © 2012-2023, Awingu 14

 Connect Awingu to your Active Directory

First Login and System Settings

Once the installation has finished, you will be able to log in to the Awingu appliance with the built-in username and password.

Port 8080 where the installation wizard was running, will not be available anymore.

Browse to the IP or DNS name of the Awingu appliance on port 80. (for example http://172.16.0.10/ ).
In the login screen, leave the domain field blank. The first time you log in, you will need to accept the privacy statement.

After logging in you will see the Awingu Workspace with 3 available applications:

1. System settings: Here you can manage your environment and make the necessary changes to the configuration.
2. API Docs: Awingu is fully API driven, this will open the API interface and show you the API documentation.
3. Dashboard: Here you can see all auditing and monitoring information.

Open the system setting by clicking on the associated icon.

Add a Domain

Awingu has no internal user database and needs to be connected to an existing AD or LDAP server. In this guide we will go through all steps
needed to link the Awingu appliance to an existing AD domain.

Start by navigating to System Settings Global Domains.

Click on [Add] and scroll-down to add the first tenant/domain:

Following parameters are mandatory:

NetBIOS Domain Name: NETBIOS domain name (e.g. COMPANY)

Name: This is the internal name used for this Awingu domain. Default is the same as the NetBIOS.

FQDN for UPN: The FQDN for the Windows domain itself, not for the AD (eg company.local).

DC/LDAP server: FQDN (recommended) or IP address of the Domain Controller or LDAP Server. E.g. ad01.company.local. Multiple servers
can be entered comma separated. The first server will always be tried first during login.
Base DN: When a user signs in, this base distinguished name (DN) is used to bind to the Domain Controller/LDAP server. This can be used
to filter access based on the organizational unit (OU).
Example without OU restriction: dc=company,dc=local
Example with OU restriction: ou=Employees,dc=company,dc=local
LDAP over SSL?: Set to “yes” if there is a certificate on the Domain Controller or LDAP server. Mind that LDAP over SSL must be enabled to
be able to make changes to passwords via Awingu.

You can validate the settings using the following PowerShell command on the AD server:

PS C:\temp> Get-ADDomain | Select NetbiosName, DNSRoot,

InfrastructureMaster, Distinguishedname | Format-List

NetbiosName : COMPANY <--- NetBios Name

DNSRoot : company.local <--- FQDN for UPN
InfrastructureMaster : ad1.company.local <--- DC/LDAP server
Distinguishedname : DC=company,DC=local <--- base DN

Optional parameters:

Copyright © 2012-2023, Awingu 15

 In the next step we will add application servers to Awingu and also import users and security groups. To do this automatically from AD, Awingu
needs a bind user and password. If not set, auto-import will not work and these servers, users and groups will need to be created manually in
Awingu. The bind user/password should be a normal user and doesn't have to be a domain admin user.

Bind Name: The username of the service account. (example: serviceuser). No domain or FQDN needs to be added.
Bind Password: The password required to authenticate the service account.

The "create bind name", "find groups" and "Privacy Policy Acceptance" parameter should not be changed. See manual for more information.

Multi-tenancy parameters:

Awingu supports multi-tenancy, which means that on a single Awingu (cluster) you can run multiple Awingu instances. To do so, add multiple
domains. To support this multi-tenancy some extra parameters have been added. In this getting started guide we only configure a single tenant. If
more tenants are added, the following parameters will be needed:

Host Headers:
Single tenant: leave blank.
Multi tenant: List all public host headers/dns names (remote.company.com) linked to the domain/tenant. When navigating to one of these
host headers, Awingu will automatically load the correct tenant.

Administrative Domain:
Single tenant: keep default ‘Yes’
Multi tenant: if set to yes, all admins in this tenant will also be able to manage the other tenants. You need at least 1 tenant with the
administrative domain parameter set to ‘yes’.

DNS Server:
Single tenant: Leave blank, in this case the global DNS server will be used.
Multi tenant: When leaving blank, the global DNS server will be used, so it must be able to resolve the server names in this domain. If this
is not the case, specify one or more DNS servers that contain the DNS information of this tenant.

Test the login

When finished, click on the "add" button at the bottom of the page. Awingu will now add the tenant and make the link with the domain controller.

Test if the settings are correct by logging in with a normal domain user:

1. Close the "System Settings" tab in the browser.

2. In the Awingu workspace, click at the bottom on the built-in admin user and select log out.
3. Try to log in with a normal domain user. You can use either the sAMAccount ( domain\user or user ) or the UserPrincipleName (
[email protected] )

If it works, you know your domain settings are correct!

Labels

All configuration in Awingu is done using "labels". Labels is a combination of a key and a value.

There are different kinds of labels:

User Labels: These start with username or group and can be used to link to a specific user or group in AD. For example the label group:
Administrators refers to the AD group Administrators, the label username:steven refers to the user steven in AD.
Server Labels: These have a more free format but for example every time you import or add an application server, appserver:ServerName
is created so it can be used directly in the configuration.
Context Policy Labels: These restrict access rights based on the user's context.
Next to these labels, also some built-in labels exist, such as all: , admin:, record:, ...

The easiest way to add user or group labels, is to import them automatically. Go to Manage Labels and click on the [Import from AD] buttons.
Once the groups and/or users are imported, Awingu will keep tracking them so when a user is added to a group in AD, no extra actions are
needed on the Awingu side.

More information on the labels can be found in the admin Manual.

If import from AD doesn't work (there is a red error message), this is probably caused by a wrong user/password in the domain
configuration. The import from AD uses the bind user specified in the domain settings.

Copyright © 2012-2023, Awingu 16

 Fine-tune the access rights

Login with the built-in admin and open the "system settings".

Next step is to further fine-tune the access. Currently all domain users can login to Awingu and only the built-in user can manage the
configuration.

Assume you have 2 security groups in AD to which you would like to limit access:

"Awingu Users" contains all users that are allowed to login.

"Awingu Admins" contains the users that should be Awingu administrators.

You can authorize groups by adding a group:<groupname> label to User Labels. The first time you use a label, you’ll have to select the
“Create new” option in the dropdown. After that, you can select the label from the list.

Go to Configure User Connector.

Here you will find the login permissions. Add the group or user labels to the “User Labels” that need to be admin in Awingu in the "Admin
Permissions" section. In this example we have added the group "Awingu Admins". By default, the “User Labels” for the “Login Permissions” are
set to "all". This means that all users in the domain can log in. In this example we have restricted the access to the Awingu environment to the
users that are part of the "Awingu Users" and "Awingu Admin" groups.

Once this is done, log out with the built-in user and log in with a user that is part of the "Awingu Admins" security group. As you will see, this user
now also has access to the Awingu admin configuration and there is no need anymore to use the built-in user for normal day-to-day configuration.

Copyright © 2012-2023, Awingu 17

 Enabling SSL
As Awingu is 100% web-based, it is important to encrypt the traffic. To do so, there are different possibilities. One of them is to use the internal
SSL Offloader of Awingu which we will explain in this chapter.

If you plan to use an external SSL Offloader, check the full manual on how to configure it correctly so the websockets used in Awingu are
passed correct. Pay attention to the needed headers that need to be passed.

To enable SSL offloading, you will need a certificate to encrypt the web traffic.

There are 3 ways to get a certificate:

1. You obtain a valid certificate issued by a certificate authority. In that case, make sure it is in CRT/Key format. If not use, openssl to convert
it to the correct format. Both individual and wildcard certificates are supported in Awingu. Check the FAQ in the support portal for help with
converting certificates if needed (for example from pfx to crt/key).
2. You generate a self-signed certificate. This is not recommended as some web browsers (especially Apple devices) do not always accept
them.
3. You use the built-in integration of Awingu with Let’s Encrypt, a free certificate authority, to automatically request certificates.

The Awingu appliance needs to be accessible from the outside world (internet) via port 443 and in case of Let’s Encrypt also from port
80! Port 80 needs to remain open for certificate renewals when using Let’s Encrypt. If it is not open, the certificate renewal won't work
and the appliance will stop working after 3 months!

Awingu has a built-in redirect feature that will automatically redirect incoming HTTP traffic to HTTPS. So no end users will be allowed to
connect via HTTP to the appliance.

Before uploading the obtained/self-signed certificate or generating the Let’s Encrypt certificate, also make sure the public DNS name you would
like to use is correctly configured.

To enable HTTPS and use the certificate, navigate to System Settings Global SSL Offloading.

Click on [Add] at the bottom to add a certificate. Awingu can handle as many certificates as needed, so you are not limited to a single certificate.

In case you want to manually import a certificate, upload the CRT and Key file or the .pfx file. Awingu will automatically extract the certificate's
name:

In case you want to automatically request a certificate using Let’s Encrypt: specify the public DNS name that can be used to access the Awingu
appliance:

Copyright © 2012-2023, Awingu 18

 Once done click on "Add". The Awingu appliance will now install the certificate and be both accessible on HTTP as on HTTPS.

Redirect HTTP to HTTPS traffic

Enable the redirect feature so that all incoming traffic on port 80 (HTTP) is redirected to port 443 (HTTPS).

To enable this redirect, you must be connected over HTTPS. So first log out of the Awingu environment and log in using HTTPS.

Open System Settings Global SSL Offloading and change the SSL Offloader from "Optional HTTPS" to "Internal SSL offloading with
enforced HTTPS":

Copyright © 2012-2023, Awingu 19

 Multi Factor Authentication
Awingu can be configured to do a second factor authentication, in addition to the login/password check.

There are 3 ways to activate MFA:

1. Use one of the Awingu built-in options:

a. Awingu OTP: Counter based
b. Awingu OTP: Time based (recommended built-in option)
2. Use a built-in connector for:
a. DUO security
b. SMS passcode
3. Use the RADIUS connector to connect to any MFA solution that supports RADIUS (Symantec VIP, RSA, Vasco, ... ) (needs support for
PAP)

Check the admin manual for further configuration details. In this getting started guide we will configure the built-in solution.

The counter based tokens are not supported by Microsoft Authenticator and a lot of other common authenticator apps.
If you would like to use Microsoft Authenticator,n use the Time Based OTP option.

Google Authenticator supports both Counter and Time Based OTP.

To enable MFA, go to System Settings Configure User Connector.

Scroll down to the "Multi Factor Authentication" section and set the mode to "Awingu OTP: Time based"

Optionally you can:

1. Set a list of IP addresses or ranges of IP addresses for which the MFA will not be asked. This could for example be used to exclude MFA
validation for connections from within in the office.
2. Set a list of user or group labels that are excluded from using the MFA.
3. Enable the Trusted Browser feature. If enabled, the user will have the option to disable the MFA check for 30 days on a specific device /
browser.

Now MFA is configured, we can enforce it for all users. On the same page, go to the top to the "Login Permissions" section and add mfa:
required to the "Context Policy Labels".

To check if it works, log in again with any user from an IP address that is not in the white list. The first time you connect, you should see a QR
code on the screen:

Open your authenticator app of choice. Scan the QR code and enter the 6 digit key. As of now, your authenticator app is linked to your Awingu
user account.

In case somebody needs to reset the token, go to Configure User Connector: Multi-factor Authentication. Click on "manage user token
count":

Click on the [Reset] button for the user whose token you’d like to reset. The next time the user logs in, they will be able to go through their MFA
setup again.

Copyright © 2012-2023, Awingu 20

Copyright © 2012-2023, Awingu 21
 Publish apps and desktops

Adding Application Servers

Before we can add applications in Awingu, we first need to add the application servers (navigate to System Settings Manage Application
Servers).

We assume you have configured a bind user / password in the "Connect Awingu to your Active Directory", so we can use the "Import from AD"
option.

Select the servers to which Awingu should connect to. Once the servers are selected, specify the number of concurrent connections that can be
made to this machine in the “Set Default Settings” section. Also set the state to enabled. When finished, click on [Import]. As of now, Awingu
knows these servers and they can be used later when creating applications or desktops in Awingu.

When adding Windows Client OS (like Windows 10 or 7) or when adding servers that do not have terminal server installed on them, the
value of maximum connections needs to be set to 1

Adding an application/VDI

Before you start adding applications or desktops, make sure the application servers are imported. If you would like to restrict access to a
certain group or list of users, make sure the user labels have also been imported!

To add any type of application (remote app, rdp app, web app, ...) or VDI, open the Applications page (System Settings Manage
Applications) and then click on [Add].

Awingu currently supports several types of applications:

Desktop Applications: Use this if you would like to make a full desktop connection to a Windows Server or Client OS.
Remote Applications: Access a Microsoft Remote Application (RemoteApp). On the Windows back end, the app first needs to be added to
an RDS collection.
RDP Applications: In this case the app is started as an alternative shell. See https://support.awingu.com/en/support/solutions/articles
/8000062982-what-is-the-difference-between-remote-app-rdp-app-and-web-app- for more details.
Web Applications: Link to a publicly available website
Reverse Proxied Web Applications: Link to an internal web application. Awingu will act as proxy server for these kind of websites to make
them also available from externally.

In thuis guide we will limit the documentation to a standard setup of a Desktop Application and a Remote Application.
For the other kindsof applications or advanced settings please have a look at the admin guide.

Generic Settings:

These settings are common for all types of applications:

Name: The application name as it will appear in the Awingu user interface.
Description: Description of the application, not visible to end users.
Icon: The application icon that will be visible to the end user in the Awingu user interface. Only ICO, JPG and PNG are allowed. Maximum
size is 100 KB.
Categories: This application will be shown in the selected categories.
Context Policy Labels: Restrict this application to only be accessible within the provided security context. This context can be a list of
countries, a list of networks or the requirement that MFA must be used.

Copyright © 2012-2023, Awingu 22

 Desktop Application Settings

When adding a desktop application, the only thing left to do is to link the application to the correct user and server labels.

User Labels contains the list of all users and groups that are allowed to start an application.
If all users can start it, use the built-in "all:" label.
If only Awingu administrators can use the app set it to "admin:" .
If you want to restrict it to a list of specific AD groups or users, set it to the group and user labels that have been added previously.
Server Labels contains the list of application servers on where the application can run.
For desktops and single apps, specify at least one application server. When multiple application servers are entered, Awingu will do
automatic round-robin load balancing over the different servers.
For web applications, the server labels should be left blank.

For example if you would like to make a specific desktop available for a specific user you first import the desktop by navigating to Manage
Application servers and importing the user by navigating to Manage Labels. There you can create the correct labels, which can be assigned to
the VDI.

Remote Application Settings

Before we can add the user and server labels for a "remote application", we need to specify which remote application needs to be started and if
we need to link the application to specific file types.

Alias: This corresponds to the alias (second column) of the published application in the collection.

File Types: Linking apps to "file types" will allow the files in the Awingu drives to be opened in the associated application.

For remote applications: make sure that on the Windows back end the "Allow all parameters" flag is set on the published application. See https
://support.awingu.com/en/support/solutions/articles/8000018507-when-opening-a-document-from-files-with-a-streamed-application-an-empty-
document-is-shown
User and Server labels: Just like for a full desktop, assign the correct user and server labels to the "Remote Application".

Awingu can also connect to an RDS broker and use the broker functionality to do the load balancing. In this case, add the rdscollection:
<collection-name> as a server label. Don't specify the different session hosts Read the admin manual for more details about adding the r
dscollection label, linking it to the broker and then linking this rdscollection label to the application)

Advanced Settings:

These settings can be used to further fine-tune the configuration. For more details have a look at the admin manual.

Unicode: In general we recommend to leave the unicode setting enabled for apps. In this case, the keyboard is detected automatically. Only
set unicode to disabled when you encounter strange behavior when typing in apps. When disabled, users have to configure the correct
keyboard settings in their profile.
Labels can be used to group specific apps for reporting.
Auto start labels can be used to select a group of users for who this application will automatically start when they log in, without the need for
them to click the application icon to start it. Enable the start in foreground option if you want this app to be active/focused.
Concurrent Usage can be set to disabled if this application can only be started once per user. For example Microsoft Outlook should be
restricted to a single start, where Microsoft Word can be opened multiple times by the same user.
Ask for Credentials can be enabled if no single-sign-on is needed and the user has to specify the credentials for this application or desktop.
Can be used to execute applications as another identity than the one you have used to log in
Notifications can be disabled if you don't want to receive any notifications from this application.
Session Merge allows you to merge this application into an existing RDP session. If there is already a remote app running on a server that is
also in the server label list of this application and the feature is enabled, then Awingu will not start a second RDP session but instead merge
this application into the existing RDP stream of the first application.
Minimum and Maximum Size allows you to specify a minimum and/or maximum size for this application. When the screen size is smaller
than the minimum size of the application, Awingu will render the application bigger than the screen size and allow you to move the application
window in the screen window either by pressing the two mouse buttons at the same time or by using a three finger touch.
Color Depth allows you to change the color depth from the default 16 bit colors to 24 or 32 bit.

Copyright © 2012-2023, Awingu 23

 Publish drives
Awingu drives allow you to access network drives directly from within Awingu. By doing so, users can for example open files directly in one of the
published apps. The Awingu drives can also be used to upload/download files or to share them.

To add a (network) drive, go to System Settings Manage Drives and click on the [Add] button at the bottom of the page.

Adding Drives is similar to adding applications. If you would like to restrict access to a specific group of users, make sure the necessary
user labels are created upfront.

The name should be set to the display name in Awingu.

The back end specifies which kind of storage to integrate with. For OneDrive or WebDAV, see the admin manual on how to configure them.

In this getting started guide we will assume the storage back end is CIFS (SMB).

The URL parameter is used to browse the storage from the Awingu appliance. Make sure it is in the format smb://<ip_or_fqdn>/path/ (Ex
ample: smb://file-server.domain.local/share )

The UNC parameter is used to open the file from the application server. Make sure it is in the format \\<ip_or_fqdn>\path\ ( Example: \\fi
leserver.domain.local\share )

The Authentication Role parameter is set by default to “user” and lets you connect to the storage back end as the logged in user. For
anonymous access to file shares, you can also change this parameter if needed.

The Context Policy Labels can be used to restrict access to these drives when a specific context is not met. For example, you can only access
the HR Drive if you are in your own country.

The <username> variable can be used in the URL and UNC path to go directly to a user specific directory . For example \\fileserver.
domain.local\users\<username>\documents will open each user’s own documents folder

The last step before the drive will be available in Awingu, is to link it to the correct user labels:

User Labels contains the list of all users and groups allowed to access this network drive.

If all users can access it, use the built-in "all:" label.
If only Awingu admins can use the app set it to "admin:" .
If you want to restrict it to a list of specific AD groups or users set it to the group and user labels that have been added before.

The access to the storage is determined by the access rights on the back end. So even when in Awingu "all:" users can access the drive,
it will only work if those users also have the necessary permissions on the storage back end itself .

Copyright © 2012-2023, Awingu 24

 Customize the branding
Awingu can be easily customized to the desired branding. To do so, go to System Settings Configure Branding.

General section: you can select the colors and also choose to have a "plain background" color or the one with the "polygon style" fading color
background.

Logo sections: if you would like to use a custom logo, you not only need to upload a new image but also set the "active wide logo" and active
square logo" option to "custom".

Login page section: if you would like to use a custom background image, first also set the "active background" to "custom". There are two
images that can be uploaded. One for large screens and one for smaller screens. Also the login text can be customized. The text allows HTML
input.

Copyright © 2012-2023, Awingu 25

Copyright © 2012-2023, Awingu 26