Index
Planning your system
Building a well designed system
Planning is an essential component of building your WebDesk System. Figure 1 below illustrates the minum recomended artecture for a production environment. Multiple display servers and multiple WebDesk servers are supported. Both server types scan be scaled laterally of vertically as needed. Thorugh expansion of the VM applance parameters (latteral expansion) or the addition of new servers (vertical expansion). If a server is experencing high load, latteral expansion, espally with WebDesk servers is preffered over vertical expansion. When planning your system it is critical to ensure that only one MySQL database is used, as this servers as the core of your system. The webdesk servers must also mount a single NFS server for the files application, however if using one WebDesk server an internal mountpoint in the VM cam be used.

Figure 1 – A simple WebDesk system
This design provides three laters with logical firewalling between each layer to provide the maximum level of isolation between systems and limit the possible north / south motion of a potential attacker. WebDesk servers utilize a self signed certificate that can if required be replaced by the customer. Display servers can either in the the appliance form factor or a customer installed and mainined Apache 2 instance. Display servers can be customized to meet the graplical requirements of the customer. However it is important to note that changes that invalidate the configuration may require the server to be reinstalled. Therefore changes to the display server should be properly tested and validated before been used in production.
Installing
Install the database schema
- Download the latest database schema from downloads.
- Deploy the SQL file to your MySQL instance.
- Create a server access user with full rights to all database tables.
- Record the username and password and connection information for later reference
Install an application appliance
- Download the Webdesk appliance OVA file from downloads
- Start the appliance
- login to the appliance with the credentials:
- Username: admin
- Password: GoWebDesk!
- sudo to root
- sudo su
- Run the install script:
- ⚠️The install script requires an internet connection and may take some time.
- ./home/webdesk/wd_scripts/install.sh
- run the configuration script:
- ./home/webdesk/wd_scripts/configure.sh
- The script will guide your configuration.
- As this is the primary server select Y to the “primary server” prompt.
- Provide the FQDN that will be used for this system
- Only one primary server can exist per environment.
- The primary server performs indexing, security and cleanup functions.
- start the service
- systemctl start webdesk
Secure the appliance
Configure SSL certificates.
For cusotmer managed certificates:
- Generate gunicorn.key and gunicorn.pem
- Save the files in /home/webdesk/certs
- Copy the CRT file to the display appliance
To generate a self signed certificate:
- As root cd to /home/webdesk/wd_scripts
- Run ./ss_cert.sh
- Follow the prompts]
- Copy the CRT file to the display appliance
Change the default password
Change the password for the admin user
- Type exit to return to the admin user
- run passwd to change the admin password
Repeat this section for any additional servers.
Install an display appliance
Configure Apache
- Download the Webdesk appliance OVA file from downloads
- Start the appliance
- Copy the Application Server certificate to /etc/ssl/certs/gunicorn.crt
- login to the appliance with the credentials:
- Username: admin
- Password: GoWebDesk!
- sudo to root
- sudo su
- Edit /etc/apache2/sites-enabled/000-default-le-ssl.conf
- Update the ServerName to reflect your system
- Update SSLProxyCACertificateFile if needed
- Updarte Define APP_SERVER to point to the Application appliance:
- Example: Define APP_SERVER https://10.0.0.11:8443
- Under local SSL provide the location of the display servers certficates and keys.
- Save the file
- Restart apache systemctl restart apache2
Change the default password
Change the password for the admin user
- Type exit to return to the admin user
- run passwd to change the admin password
Repeat this section for any additional servers.
First login
- Conenct to any deployed display server in a web browser using HTTPS.
- ensure the domain is local
- Enter admin and the password provided during the configuration of the primary server.
- Inital login should provide the Admin, Files and Audit applications by default.
Admin Portal
Users Tab
This provides the ability to create and update local users defined on the webdesk system. LDAP, Active Directory and SAML users will automatically be created. However it is important to note that these external users will have their home login domain appended to the username with the @ symbol for example user@myaws or user@ad_server. These users will also be created in a locked state, as security is managed by the external authentication source provided in the login domain. It is important not to manage external users from the admin console unless a local override is required.
Local override
In the even that the external authentiction provider is unreahcabe local override can be used to provide emergency access to the system using the following procedure. This is however designed for temporary emengecy access and, due to the face that many security features are bypassed should never be used long term.
- Select the user you whish to override.
- Provide a password for the user.
- Select the enabled checkbox.
- Save the user.
- Ask the user to login, using the local domain and their full webdesk username for example user@brokenldap
- Once the tehnical issue has been resolved disable the local account.
Working with groups
Inside the WebDesk system groups provide the mapping between users and appplications. Local users are mapped in the user account object itself. LDAP and AD users are mapped based on the group attributes that are returned from the directory. Groups must be manually created with with identical names to the AD / LDAP group for map to the webdesk group and linked applications. If a group does not exist in WebDesk the mapping is ignored. For SAML groups the SAML ID must match the group ID provided in the SAML assertion. By design the SAML ID is independent from the group name, allowing for human readable names in the admin console.

Figure 2 – Group mapping diagram
Working with applications
Settings
Login domains
Licences
Checking system status
