AnyX Guide Topic: resource

  • Shares

    Shares

    agilicus-anyx-share

    Shares

    Securely sharing directories from individual servers or desktops has never been simpler. No VPN, no ransomware. No client to install.

    Secure File Sharing

    Securely sharing directories from individual servers or desktops has never been simpler. No VPN, no ransomware. No client to install.

    Theory of Operation

    General Steps

    The Secure File Sharing is facilitated by an Agilicus Connector on the host(s) you have files you wish to access. Creating this is very simple, the only configuration option is a name.

    Once the Connector is installed, you can later add new directories to share, modify who has access, and remove the share entirely, all from the admin user interface. The Connector will automatically keep itself up to date and pick up new configuration. Set it and forget it.

    To create a new Share, you will walked through the steps in the Admin web interface. First, select the Connector you have previously installed. You may have multiple shares on the same Connector.

    36c33495 image

    Now we give the Share a web URI name. This is something that will show up for the end-user, they will be given instructions to mount something like https://file…/NAME.

    You must also configure a globally-unique name for this Share. You will see this in the Administrative interface, in the audit interface, etc. These may be the same if you wish.

    e3f7b7d6 image

    We will now supply a “Local directory”. This is the directory on the machine the Connector is installed on. See the note below on permission, it is important that the Connector have access to it.

    9b3c3248 image

    At this stage we are complete. As an administrator you will be given instructions on how to mount the Share, which you may use to test it is working correctly. Generally, each user in your organisation will use Profile in order to request and use a Share.

    To manually mount the Share, there are 3 parameters:

    • URL. This will look like https://files.YOURDOMAIN/URI-NAME
    • Username: this will be the email-address you use with the Agilicus system (e.g. your Active Directory login, your Google Login, etc)
    • Password: this will be an access token. This is generated for each user independently. End users may request access, or request an Access Token via Profile.

    The Profile interface will give these parameters to each user.

    d664854d image

    Permissions, Access Control

    Permissions work similarly to Applications. Each Share has 3 main permissions (Owner, Editor, Viewer). Users may be individuall granted permissions per share, or, Groups may be used. We recommend Group-based access.

    NOTE ON PERMISSIONS

    Many Microsoft products (e.g. Microsoft Office) will create a Lock-file or a Temporary file in the same directory. This can be confusing when using a permission other than Owner.
    For example, if the permissions are ‘Editor’, a user can update an existing file, but not delete it nor create new files. If they open a Microsoft Word file, they may see an error indicating that the temporary file cannot be created. Unless you are using a small set of well-known applications, we recommend using Owner permissions.

    NOTE ON MAXIMUM FILE SIZE

    The default limit for maximum size on some Windows clients is 50MiB.
    We recommend setting FileSizeLimitInBytes to a larger value, e.g. 500MiB. This is located in HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
    See https://learn.microsoft.com/en-us/iis/publish/using-webdav/using-the-webdav-redirector for more information.
    This setting is on the client (where you will mount the share).

    Access Request

    da03f4d9 image

    Variable Expansion

    In some cases you may wish the path to be templated, for example, mount /PATH/USERNAME. You may do that with string substitution. Variables may be expanded in the format of ${VARIABLE}.

    The following variables are supported:

    • AGILICUS_USER_FULL_NAME
    • AGILICUS_USER_FIRST_NAME
    • AGILICUS_USER_LAST_NAME
    • AGILICUS_USER_EXTERNAL_ID
    • AGILICUS_USER_EMAIL
    • AGILICUS_USER_EMAIL_NAME
    • AGILICUS_USER_EMAIL_DOMAIN

    Linux Specific

    Permissions

    The Agilicus Connector runs as an unprivileged system user. This means that, by default, it will not have permission to read files in a shared directory created by you. To give it access, create a group whose purpose is to group users who have permission to read and write shared files on the machine. Add the agilicus user to the group, then give that group permission to access the shared folder.

    # Set up the shares group and add the agilicus user to it
    sudo addgroup shares
    sudo usermod -a -G shares agilicus
    
    # Configure the share and all files within it to allow access to the shares group
    sudo chgrp -R shares my-shared-directory
    sudo chmod -R g+srw my-shared-directory
    
    # Ensure files created by the connector and other users have the proper permissions
    sudo setfacl -d -m g::rwx my-shared-directory

    Windows Specific

    Permissions

    When installing the connector, by default it is installed as the ‘SYSTEM’ user. This user is typically appropriate for running a service, but there are times it may not have adequate permissions to access a specific folder for a share. When this happens you will see a ‘List Error’ trying to access the share from profile, and it won’t mount properly for end users. This can happen in particular when sharing from a network drive, where local permissions don’t grant access.

    When this happens, it may be appropriate to assign it to a different user. This user might be a domain admin, a local admin or a separate user which you giver permission to access the folder being shared. This can be done by opening the Microsoft services applet, finding the ‘Agilicus Connector’ service, and changing the Log On option to run as a user with access to the share.

    When you change the user which is running the connector, you must also ensure that the user running the connector has full read+write permissions to the “C:\Program Files\agilicus\agent” folder.


    Manual Mount with Map Network Drive

    A Share may be mounted using the Windows Explorer, just like any other Share. No special software needs to be installed. You will need the 3 parameters

    6fc80895 windows 1
    ac8f646a windows 2

    Automatic Mounting

    For end users with the Agilicus Launcher installed on the desktop, a Share can be automatically mounted/refreshed. This is particularly useful in conjunction with Multi-Factor authentication. In those mode, a ‘drive-letter’ or ‘mount path’ is configured as per below image, and the Share will automount for each user.

    359fb87c image

    Linux Specific

    For mounting a share automatically on Linux, fill in the ‘Linux path’ field on the client configuration shown above.

    On Linux some extra setup is necessary in order to make automatic mounting work.
    The davfs package needs to be installed with the non-root mount option enabled
    On debian-based systems like ubuntu, you would run the following:
    sudo apt install davfs2
    In the package configuration screen, choose the left option.

    68409c38 image

    Next add you user to the davfs2 group:
    usermod -a -G group $USER
    You will have to reboot for this to take affect.

    Lastly, for each share add an entry into your /etc/fstab file matching the following
    https://<YOUR SHARE URI> <LINUX PATH> davfs rw,user,noauto 0 0
    This must match the uri for the share and the path configured to mount it.

    From now on, whenever you run refresh on your desktop, the share will automatically mount!

    Advanced Setup: Local Routing Performance

    f8011f4d image

    This is an optional section. It shows how to route traffic locally, from a machine with direct access to the connector facilitating the share. In order to achieve this, we rely on a local DNS (and split horizon DNS). The Connector will expose a local port (443) with the same hostname and certificate as externally.

    In order to improve performance and decrease bandwidth usage, it can be useful to have your local users access a share directly, rather than over the internet. While this still requires the users to initially login to the Agilicus platform, it enables the network traffic for accessing the share itself to never leave the premises.

    The end goal would look something like this at right.

    To follow this guide, you have to already have a share created. Ensure that the share is working.

    New shares will have the feature enabled to automatically support this task.

    After you have your share working, you will need to ensure your site’s network is setup to access the share. By default, it will be exposed on port 443 (https) on the computer the connector is running on. If there is already a web server on that site, the connector could conflict and be unable to serve the traffic. In those cases, you will need to resolve the conflict and move either the agent or the website.

    For each connector with assigned File Share resource, exposing its local server TCP port 443 simply requires enabling via the “Manage Routes” dialog:



    By default we can bind to all the local server interfaces. If there is a segmentation requirement, we can specify the IP address the connector should only bind to.

    The next step is setting up DNS to resolve share addresses to the connector onsite. You will need to configure the local dns server to route the domains for Agilicus shares to the local connector. Agilicus shares follow the pattern: <share-name>.share.<your agilicus domain>. For example, if your share is named  ‘accounting’, and your domain is ‘cloud.acme.org`, then the share would be `accounting.share.cloud.acme.org`. You can also see what domain your share is on in profile by clicking ‘Manual Mount’ and checking the URL.

    9585b024 image
    320265f5 image

    There are two choices available for how you configure your local dns entries. 

    1. Create a wildcard record *.share.<your agilicus domain> to direct all shares to the local connector. This will work correctly provided that all shares for your organization are available from this connector
    2. Create a record for each specific share.

    Whether you choose 1) or 2) depends on your specific network layout and your dns server’s capability for wildcard entries.

    For example with a share named ‘test’, and the local connector on ‘192.168.122.1` a config in OPNSense would look like this.

    f5b17215 image
  • Services

    Services

    5293bad2 services

    Services

    Services

    A service is a basic primitive of a Network Resource. It consists of a set of coordinates that ultimately resolve to a TCP host + port.

    Configuration includes:

    • Service Name: This is the name the service is accessed via as a user (e.g. the ssh name they will use) or one of your Application Resources will use to address
    • Hostname/IP: This is the name that the Secure Exposed Agent will resolve. It is often the same as the service name
    • Port: the TCP port # (0-65535)
    • Override IP: typically blank, but, in the event that DNS is not available, the IP address of the Hostname.
    • Via Connector: this is the method and connection to reach the Network Resource.
    • Accessed via TLS: If checked this connectons to this Network resource will be initiated via TLS
    • Verify TLS: if TLS is checked, if this is checked, the destination certificate is confirmed
    • Protocol: currently only TCP
  • Zero-Trust SSH Access

    Zero-Trust SSH Access

    7423582c ssh terminal

    SSH Access

    Any identity provider.

    Multi-factor authentication.

    Direct SSH access, end-to-end encrypted.

    Web access from any device, or, existing SSH client.

    SSH Access via Zero Trust

    SSH by its very nature is end-to-end encryption with strong protection against Man-In-The-Middle attacks. All servers need to be accessible via SSH to be manageable, often by external users (e.g. vendors, outsourced NOC, etc). However, despite SSH being strong on encryption it is challenging on accessiblity. The servers are typically on private networks (e.g. Virtual-Private-Cloud VPC, internal network VLAN’s, etc). Making them directly accessible to the Internet can be dangerous (we would have to somehow police that all users have passphrases on their keys, that we don’t have passwords allowed, etc.). SSH jump-boxes add a step to the workflow, are difficult to ssh-port-forward and scp through. VPN access is difficult to secure on a per-server basis, often being all-or-none.

    In this guide we will setup the Agilicus Zero-Trust Network Access to directly access arbitrary SSH servers. The users will see them as being directly Internet connected. The users will have zero configuration (after the initial setup). Users can be individually authorised on a per SSH server basis. Additionally, users can be federated for identity by any upstream identity provider, allowing an external vendor to be identified by their own corporate Azure Active Directory, an independent contractor via their Google login.

    The data flow is such that the SSH TCP session is intact from the client to the server: the hostkeys are unaltered, SSH anti-tamper mechanisms are unperturbed. SFTP just works.

    d6c678de ssh data flow

    The end user can use any SSH client (ssh command line, mobaxterm, putty, etc), with no complicated config to remember. The system administrator can gate access on/off per user, and, see an audit trail of who has accessed what, when, from where.

    SSH Access Setup

    Note: you can use a site-to-site VPN via IPSEC, or use the onsite Agilicus Connector for each pool of servers. These instructions assume the latter.

    1. CREATE ORGANISATION

    Your Organisation lets you setup your identity providers, your DNS name (CNAME), and control your users.
    See SIGNUP

    2. SETUP IDENTITY

    You can enable Google, Apple, LinkedIn as check box items. You may also wish to enable Azure Active Directory
    Also setup initial users and group membership.

    3. CREATE CONNECTOR PER SITE

    Each pool of servers needs a method to reach it. This can be a site-to-site VPN, or an on-site connector. Install a connector now, this may be on each SSH server, on 1 of the servers that can reach the others, on a machine in the same network, its up to you.

    4. CREATE SSH RESOURCE

    The SSH resource has a unique name, a upstream host-name, and upstream port. Configuration will be automatically created for desktop clients such as OpenSSH or Putty.

    5. ASSIGN PERMISSIONS

    We must now assign ‘Owner’ permission to each user or group that should be able to connect. See “Resource Permissions” for more information.

    SSH Resource Setup

    4 steps:

    1. Select the connector (the site on which the underlying SSH resource exists)
    2. Create a name for the SSH resource. This will appear as a valid hostname and must be unique within your sub-domain. Feel free to use a pattern, e.g. ‘site-host-ssh’.
    3. Select the hostname/IP and port that the SSH server is on in that remote network.
    4. Assign permissions (who can use this SSH resource)
    aa436223 image
    1920e382 image
    20441f67 image
    ab42d7ba image

    The underlying SSH resources will also show up under Network Resources.

    Automatic Sign-In (cached credentials)

    In some cases you wish end-users to be able to sign in via the web interface, but do not wish to share the credentials with them. For this purpose Agilicus has a secure credential store and key or password stuffing. You may configure this during the creation of a new SSH resource, or, later on the existing resource as below.

    Note: the SSH key cannot be retrieved from the system. Once you have configured it, it is one-way encrypted, if you wish to change it later you may, but you must keep your own copy.

    e8c31ed8 image

    Using the SSH Resource

    If you have not done so, install the Agilicus Launcher on your desktop (Windows, Linux Mac) from profile (https://profile.YOURDOMAIN). The Launcher support runs on demand, it is not a service. It will automatically configure OpenSSH (Windows, MAC, Linux), or Putty (Windows).

    Note: The Launcher will configure OpenSSH if the file ~/.ssh/config exists. If you have not used SSH before, you might need to create this file.

    At this stage, you can ssh directly to the server, using the name you gave above. For example, if in step 4 you called the SSH resource “foobar”, you can type ‘ssh foobar’. This might bring up a browser to identify you and/or perform multi-factor authentication. The data flow is as shown below.

    Zero-Trust SSH Data Flow
  • Forwarding

    Forwarding

    forward

    Forwarding

    The Agilicus AnyX forwarder allows moving TCP from site to site in a mesh, ignoring firewalls and NAT.

    Concepts

    A Network Resource is an arbitrary network IP address and port. This might be a Remote Desktop, a Database, an ERP system. Typical access control is done via network access control lists. To expand this via cryptographic-based zero-trust networking, the Agilicus system can expose the Network Resource via a Connector and then provide authentication and authorisation based security on it onwards to other users or systems.

    A common use case for Forwarding is a need to have a Network Resource available from one site to another. As an example, consider a small company. It has two offices. Each office has a typical small business router and a few staff. One of the sites runs a database which is used by a desktop application.

    8477e0e4 network resource forwarding

    In this case, consider the following approach:

    1. Install Connector on site with database (on the database server or another)
    2. Install Connector on site needing access (on the desktop running the application, or another)
    3. Create a Network Resource for the database. Attach it to the proper Connector
    4. Create a Forwarding Resource on the site needing access. Join the two.

    To keep the terminology straight, a ‘network’ is the destination. It is where traffic *leaves* the Agilicus mesh, and onwards to the ultimate resource. A ‘forwarder’ is the ‘source’ or ‘ingress’, its where traffic enters the Agilicus mesh.

    Thus if you had a Linux device you wanted to be able to ssh to unattended from a synology NAS, you would install a connector on the Synology, a connector on the Linux server, a network would be created attached to the Linux connector with ‘localhost:22’, and, a forwarder would be created attached to the synology connector listening to e.g. localhost:2222

    You will be asked a few questions:

    1. destination IP/hostname. This is the hostname or IP as resolvable by the connector installed on the site with the database. It will typically be the same as you would enter in your desktop application.
    2. destination Port. Same as 1
    3. Source IP/hostname. This is typically left blank(all), meaning the host with the connector will allow any local network host to use it. If you wish to lock it down to the local desktop consider entering ‘localhost’ here. By default this is ‘localhost’ (meaning the application wishing to connect must run on the same host as the Connector). You may change this to ‘0.0.0.0’ (meaning any host in the same network may connect.
    4. Source Port. This is typically left blank (meaning same as destination). In some environments you may wish to use a different port here (for example, if the destination port is privileged, <1024, since the Connector runs unprivileged, you may e.g. use 80 for the destination port and 8080 for the source port)
    65734922 image
  • Zero-Trust Desktop Access

    Zero-Trust Desktop Access

    remote-desktop-style

    Microsoft Remote Desktop

    If you have Windows servers (or desktops) you need to access from any user, on any device, from anywhere… This is what you need

    Microsoft Remote Desktop

    Most of your applications are now modern, responsive web apps. However, you still have some native Desktop applications. You need to be able to access them remotely, safely, simply. You need to be able to grant access to specific Desktops to specific users, but, they may not work for you. Your Desktop may run in a site without a public IP, or a configurable firewall allowing safe inbound access. Perhaps your house, perhaps a branch office.

    In 10 minutes you can have 1-click remote access to that Desktop. With no configuration onsite, no change to the Desktop or the firewall.

    Via Remote Desktop Protocol, or via VNC.

    Via a Native Client, or via a web interface.

    Desktop Access Setup

    c4228795 zero trust desktop access.embed

    Note: you can use a site-to-site VPN via IPSEC, or use the onsite Agilicus Connector for each pool of servers. These instructions assume the latter.

    1. CREATE ORGANISATION

    Your Organisation lets you setup your identity providers, your DNS name (CNAME), and control your users.
    See SIGNUP

    2. SETUP IDENTITY

    You can enable Google, Apple, LinkedIn as check box items. You may also wish to enable Azure Active Directory
    Also setup initial users and group membership.

    3. CREATE CONNECTOR PER SITE

    Each pool of servers needs a method to reach it. This can be a site-to-site VPN, or an on-site connector. Install a connector now, this may be on each SSH server, on 1 of the servers that can reach the others, on a machine in the same network, its up to you.

    4. CREATE DESKTOP RESOURCE

    Each Desktop host will require a Desktop Resource to provide the coordinates. This will include a name, and hostname/IP. The Hostname/IP will be in the internal coordinates.

    5. ASSIGN PERMISSIONS

    We must now assign ‘Owner’ permission to each user or group that should be able to connect. See “Resource Permissions” for more information.

    6. CONNECT

    From https://profile.YOURDOMAIN, you may open the Remote Desktop. By default this will launch your native remote desktop client (e.g. mstsc). You may also install the Launcher from the Profile, will give you an icon on your regular operating system start menu.

    Detailed Desktop Creation

    87da6413 image

    The ‘Desktops/New’ asks 3 questions:

    1. Connector. This you will have already setup, you need 1 per site (or more if you wish, e.g. 1 per host)
    2. Name. This will be the ‘name’ you assign permission to, it will show in the audit, the end-user will see it
    3. Hostname/IP. This is how you would address the Desktop within the (private) site.

    Once you have completed these steps, as an Administrator you will be offered the opportunity to download an RDP file. This will open in your native Remote Desktop application (on all platforms). The Desktop will become available approximately 1-2 minutes after you apply the config. (This is to test the configuration)

    You may now assign permissions (by group, or by user). Each user who has access will see, in https://profile.MYDOMAIN, an icon for the same Remote Desktop. They may also install the Agilicus Launcher which will create start menu icons automatically.

    The detailed steps and screen shots are shown below.

    Some versions of Microsoft Windows (e.g. Windows 10 Home) do not support Remote Desktop Server. You may try a different OS, you may try VNC, or, there are some workarounds.

    Connection Parameter Override

    End users may wish to configure specific overrides regarding their local displays, resolution, clipboard, etc.

    The configuration options are found in their Profile (https://profile.YOURDOMAIN), under their account icon.

    Users may choose to passthrough their microphone or audio output, clipboard (cut and paste), usb devices.

    Some remote desktop servers have multiple displays, these can be passed through if desired.

    The user may select dynamic resolution (e.g. they can resize the current window and it will resize the remote), or a specific dimension.

    NOTE: You may need to change the Network Level Authentication on the server

    Disabling-and-Re-Enabling-NLA-Settings-Via-System-Settings
    1. Press Win + R to open the Run command dialog box.
    2. Type sysdm.cpl and press Enter to open the System Properties window.
    3. Navigate to the Remote tab.
    4. Uncheck the Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended) box.
    5. Press Apply and then press OK. From there, restart your PC to save these changes.
  • Resource Groups

    Resource Groups

    group

    Resource Groups

    Resource Groups

    Resource Groups are a means of applying a common permission across a set of resources (connectors, applications, shares, etc).

    Common uses for Resource Groups are:

    • all resources on a site
    • all resources of a type
    • all resources of a manufacture
    • all resources used by a specific Agilicus Launcher

    A Resource Group may contain other Resource Groups, allowing nesting. Each Resource Group can contain 0 or more Resources.

    A common overall strategy is to use Groups (of users) assigned by role, assigning permission of these Groups to Resource Groups by role/location/device-type etc.

  • Launchers

    Launchers

    e05afe22 start

    Launchers

    The Agilicus AnyX Launcher acts to integrate the desktop environment with the online, browser environment. It can act to:

    Launchers

    The Agilicus AnyX Launcher acts to integrate the desktop environment with the online, browser environment. It can act to:

    • mount a share
    • open a remote desktop
    • SSH to a host
    • Run an executable

    Install Browser Extension

    A browser extension is available which simplifies the integration between the desktop and the browser. Install from the Chrome Web Store.

    Once installed, in the users web Profile, they may directly mount a share, open a local application, open a remote desktop with native tool.

    Install Desktop Integration

    The desktop integration is installed from Profile. Navigate to https://profile.<YOURDOMAIN>. Once signed in, see the Launcher menu, select the ‘Install’ button. This will download an executable to be run.

    LAUNCHER FILE NAME

    Note: the launcher download is named specifically for each user. Do not rename the file before running.
    On a MacOS device running Safari, it is possible that the browser will append a ‘.html’ to the file name during the download, please remove this before running.

    Desktop Application Launcher

    A launcher is a method of encapsulating all of the resources a desktop ‘fat client’ needs to operate.

    Imagine a desktop ERP system. It needs a Share mounted in a specific location. It needs a TCP forwarded for a database. The desire is the end user can click a single icon and launch it, optionally being challenged for multi-factor authentication.

    To use, first configure the individual resources (e.g. a Share, a TCP Forwarder, etc.). Give them unique names. Now, add a Launcher. The end user will see this appear as an Icon on their start menu. When launched, the application given will open, and the resources are guaranteed to be present. The user may first see a browser open to challenge their identity if it is not known.

    1fc85365 image
  • Agilicus Launcher (Desktop)

    Agilicus Launcher (Desktop)

    e05afe22 start

    Agilicus Launcher

    Jump directly to platform specific installation instructions are shown below for Microsoft Windows, Apple OSX, Linux.

    Agilicus Launcher Desktop Configuration

    The Agilicus Launcher provides a means of interacting with the user for the purposes of:

    • launch a desktop application with wrapped networking
    • mount / update mount on a share
    • ssh proxy command

    It may be used standalone, or, directly integrated to a browser. This can be particularly useful to:

    • allow a system-administrator to manage applications and shares remotely via an API
    • provide multi-factor authentication on a Share
    • Automatically configure putty, openssh for SSH access
    • run a desktop application with wrapped networking

    When installed in this mode, the Launcher will update itself periodically as it is run. It will initially query the user, and, then, interact again as needed to refresh credentials.

    The user installation is very simple: download and run a single file. It will place an entry on the users’s menu called ‘Refresh’ as well as one icon per Launcher. The user can now launch individual applications via an icon. Or, if needed, the user can refresh their shared drives (optionally being forced to re-authenticate with multi-factor authentication) by selecting Refresh.

    Install

    Platform specific installation instructions are shown below for Microsoft Windows, Apple OSX, Linux.

    Microsoft Windows

    Note: Installation on Microsoft Windows does not administrative privilege.

    1. Open Profile

    Open Profile (https://profile.YOURDOMAIN) in your browser. We recommend Google Chrome or Microsoft Edge since they support the Agilicus Launcher Extension interface.

    2. Install Desktop Integration

    Select ‘Install Desktop Integration’ button in top bar.

    3. Install Extension

    (Optional). Without the extension there is no browser ⇔ desktop integration, but the ‘Start’ menu can be used independently.

    4. Install Launcher

    Download and run. No configuration steps or questions are needed.

    Apple OSX

    Note: Installation on Apple OSX requires administrative privilege, but later running and upgrading does not.

    1. Open Profile

    Open Profile (https://profile.YOURDOMAIN) in your browser. We recommend Google Chrome since it supports the Agilicus Launcher Extension interface.

    2. Install Desktop Integration

    Select ‘Install Desktop Integration’ button in top bar.

    3. Install Extension

    (Optional). Without the extension there is no browser ⇔ desktop integration, but the some local desktop tools such as ssh can be used independently.

    4. COPY code to clipboard

    select COPY to put a security code on your clipboard

    5. DOWNLOAD package

    Download the installation package

    6. Install package

    Install the installation package using defaults provided.

    7. Paste Code

    When prompted, right-click and paste the code you copied above.

    Linux

    No administrative (root) permissions are required.

    1. Open Profile

    Open Profile (https://profile.YOURDOMAIN) in your browser. We recommend Google Chrome since it supports the Agilicus Launcher Extension interface.

    2. Install Desktop Integration

    Select ‘Install Desktop Integration’ button in top bar.

    3. Install Extension

    (Optional). Without the extension there is no browser ⇔ desktop integration, but the some local desktop tools such as ssh can be used independently.

    4. Download Agilicus launcher

    Download the launcher executable

    5. Enable Execute Permission

    Either from the file browser or a shell, make the launcher executable

    6. Run Agilicus launcher

    No configuration options are needed.

  • Sign in With Apple

    Sign in With Apple

    8584ed0a image

    Sign in With Apple

    Some consumers may wish to use ‘sign in with apple’. This is not common, we recommend using Google and Microsoft since they are simpler to administer, and simpler for the end user to use.

    Sign in With Apple

    8584ed0a image

    In a “Sign In With Apple” flow, the user will supply an email-address they used to register their Apple account. This might be @hotmail, @gmail, etc. This is typically done automatically by their browser or device.

    Some users may have a different ‘appleid’ than the ’email’ on file with Apple.

    In the Agilicus system, the ‘Email’ that is shared (shown in the screen shot at the right) should be used in the “Users” screen to link the user.

    It is important that the user not use the “Hide My Email” option, since in that case there is no method to link the accounts.

    a7871a46 image

    NOTE: “Share My Email”

    It is critical that the user select ‘Share My Email’. This is required to link the account between the Apple system and the Agilicus system. The user will not receive any email.If the user inadvertently selects ‘Hide My Email’ or does not provide a Name, they must delete their account in the Apple account settings, and then sign-in again.The user might otherwise see an error such as to the right.

    If the user inadvertently selects “Hide My Email”, they must correct this through their Apple Account settings by removing the ‘Agilicus’ Application, and then signing in again.

    To check if you have inadvertently selected ‘Hide My Email”, you can check in your iCloud settings (via your Apple device). First, open iCloud. Then select ‘Hide My Email’. If you see an entry for ‘Agilicus’ this means you have declined to provide your identity for purposes of Authentication.

    80cf6d7c image
    123749b3 image
    95358e1b image

    In order to correct this, first remove the Apple ID Login. Once removed, you may sign in normally (remembering to keep ‘Share My Email’ selected).

    ca7a0978 image
    744c2391 image
    a2cd6d4c image
  • Resources – Overview, Concepts

    Resources – Overview, Concepts

    90cf7af9 clickonce

    Resources

  • Real VNC & Raspberry Pi

    Real VNC & Raspberry Pi

    ae2c7d35 raspberry pi

    Real VNC & Raspberry Pi

    How to setup Real VNC to interoperate with standard VNC on your Raspberry Pi.

    Real VNC & Raspberry Pi

    The Raspberry PI supports multiple operating system distributions. The default used is often Raspbian, which has a VNC-similar server installed called Real VNC.

    Real VNC is not enabled by default. It also uses a proprietary authentication scheme by default.

    To enable VNC on your Raspberry Pi and access via Agilicus Any-X, you may use the option panel, changing the Authentication from “Unix password” to “VNC password”. Or, if you prefer, you may edit the text files as below.

    1. Add Authentication=VncAuth to /root/.vnc/config.d/vncserver-x11
    # cat /root/.vnc/config.d/vncserver-x11
    _AnlLastConnTime=int64:0000000000000000
    _LastUpdateCheckSuccessTime=int64:01d8f9c1abad5c0a
    _LastUpdateCheckTime=int64:01d8f9c1abad5c0a
    Authentication=VncAuth
    Password=d00971cd8cacb99e
    ViewOnlyPassword=d00971cd8cacb99e

    2. set a VNC password (optionally read-only)

    $ vncpasswd -service
    Password:
    Verify:

    Now enable/restart the vnc service:

    systemctl enable vncserver-x11-serviced
    systemctl restart vncserver-x11-serviced

    Encryption

    The Real VNC Server supports a super-set of the Encryption supported by Agilicus AnyX. You may need to set “Prefer On” to allow the two sides to negotiate.

    2f723b59 image

    At this stage you can follow the standard directions to create a VNC Desktop

    1. Resources/Desktops/New
    2. Add user permissions to new desktop
    3. Open Profile and select the desktop

  • VNC Desktop

    VNC Desktop

    VNC Desktop

    VNC Desktop

    Access any machine’s display, whether embedded or server, from a browser, from a local client.

    Allow multiple concurrent users, see what each are doing.

    Read-only and read-write access.

    VNC Desktop Overview

    The VNC Desktop feature allows browser-based use of remote graphical-oriented resources. This can include traditional operating systems like Windows, Linux, MacOS, but, also, includes embedded devices such as HMI.

    VNC has very weak intrinsic security (a read-only password, a read-write password, but no username). These passwords are in turn very weakly encrypted (3DES), and, must be 8 characters. As a consequence, it is not safe to use by itself with e.g. port-forwarding.

    Agilicus AnyX adds a Zero Trust layer, with strong identity and modern encryption, making these safe to use remotely.

    Setup

    Assuming you have the VNC Server already running and available, you can create and access a VNC Desktop by:

    0a2da709 image
    1. In the Agilicus Admin interace, ‘Resources/Desktops/New’, select ‘a new VNC remote desktop
    2. Select the connector which is adjacent to the VNC Server
    3. Give this VNC Desktop a name. You will use this in the Profile to select the machine
    4. Select the address (as the connector would see) it of the VNC server. E.g. on the machine running the connector, you should be able to ‘ping’ this hostname. NOTE: if the connector is on the same machine as the VNC server, you may need to ‘enable loopback connections’ in the VNC Server configuration.
    5. Optional. If you wish to have the Profile VNC Web interface auto-sign-in (after you have presented your single-sign-on-credentials) you may enter the read-write (and/or read-only) password of the VNC server. If these are set, users may be forced into a read-only role by permissions later.
    6. Assign permissions to who may use this desktop. If ‘viewer’ is selected, and the read-only password was given above, the user will be auto-signed-in as a read-only user.

    At this stage, you can open https://profile.MYDOMAIN and you should see this VNC resource on Desktops.

    7ad695e6 image
    462a4b9f image
    d6e4fb6b image
    a08bf349 image
    fe55711e image