Agilicus AnyX Frequently Asked Questions

Agilicus AnyX Frequently Asked Questions

Have a question which is not answered here? The Chat icon goes directly to our team, or feel free to email info@agilicus.com, or, use the Get In Touch form.

CONTACT ✉
BOOK MEETING 🗓
SIGNUP ↗

Key Concepts

When you initially signed up to the Agilicus AnyX platform, you choose a domain (either your own DNS name with a CNAME, or, an Agilicus-supplied domain). Your domain looks something like ORGNAME.agilicus.cloud. You will have received a welcome email with this information, as well as have been automatically signed-in in your browser to e.g. https://admin.ORGNAME.YOURDOMAIN.
Open the admin web user interface at https://admin.YOURDOMAIN/
Open the profile web user interface at https://admin.YOURDOMAIN/

Initial Setup

See “Firewall Configuration“
See “Theming“
Some customers have issues with their outbound or next-generation firewall. It might block their new domain name they use with Agilicus AnyX (e.g. connect.mydomain.com). We recommend configuring your firewall by hostname if possible. If it must be by IP, this could theoretically change in the future.
See “Firewall Configuration” for the specific rules.

Invoices, Billing

See “Organisation/Billing” in your admin portal (https://admin.MYDOMAIN). From here, select ‘VIEW/UPDATE PAYMENT INFORMATION”
See “Organisation/Billing” in your admin portal (https://admin.MYDOMAIN). From here, select ‘VIEW/UPDATE PAYMENT INFORMATION”
See “Organisation/Billing” in your admin portal (https://admin.MYDOMAIN). From here, select ‘VIEW/UPDATE PAYMENT INFORMATION”

Authentication, User Permissions

Agilicus AnyX joins together (federates) a set of Identity Providers (IdP). As an end user, you will see this as e.g. ‘Sign In With Google’ or ‘Sign In With Microsoft’. The AnyX platform in turn presents these federated IdP as a new IdP. The Upstream Identity Provider is it original one that the user interacts with (e.g. Microsoft, Google, Active Directory Federation Services, etc).
You may use Time-Based One-Time Codes (TOTP) (e.g. Google Authenticator, Microsoft Authenticator, Authy, etc), or, any of the standards from the WebAuthn standard set (e.g. USB-based like YubiKey, Passkeys, TPM-based, biometric, etc).
By default you will have a ‘Shared’ Microsoft Identity Provider enabled. This allows anyone to sign in with any Microsoft account: Azure, Office 365, Outlook.com, etc. This is useful for 3rd parties, vendors, etc.
If you wish to force your users to sign in with your own Azure tenant (e.g. to enable auto-create), you may create a ‘Custom Authentication Issuer’.
On the “Access/Resource Permissions” menu in your administrative web interface you can control which users or groups have which permissions on a resource. See “Permissions” for more information.

Shares

When creating a new Agilicus share the Agilicus connector cannot see network mapped drives because it runs as the local system user, and not a logged in user. This means that it cannot see shares which are only typically mapped for logged in users. When this happens, if you browse to the share in profile, you will get a ‘list directory error’ as the connector cannot see the directory. In order to correct this, create a link to the network drive on a local drive eg mklink /D C:\myLink \\127.0.0.1\c$. Then use the link as the path for the Agilicus share, in the example C:\myLink. You may also need to change the user which the connector runs as is in order to access the drive.
Admin can enable user requests in the admin portal. This eases the process of giving or denying access of a user, but a user will see all the available resources
From the admin portal, Organisation > Overview (check the Disable User Requests checkbox)
All admin will receive notifications upon a resource request from users
You may refer here for more information on permissions
No, we do not store anything from your share. All of it lives on your file server. You have the sole data at rest on your system, and, data in motion is encrypted end to end.
If you see a List error and the folder exists, often that means that the account the agent runs on cannot see the folder being shared. This may mean that the connector needs to run as a different account, or you need to follow the above steps for Sharing network mapped drives. See product-guide/product-guide-shares for more information.

Resource Setup and Configuration

The Agilicus Connector needs to be able to reach any service it is used to expose. For a share, this means running on a machine with access to the files. For a Desktop, it means being able to reach via TCP (port 3389 or port 5900 for RDP or VNC typically) the destination system. This might mean running on the same system, this might mean running on a device on the same network segment or inside the same firewall.

Diagnostics and Troubleshooting

End users interact with AnyX via Profile (at https://profile.MYDOMAIN). Each resource is represented by an icon. There are 3 ‘tabs’ (mine, requested, all). If an icon does not show in the ‘mine’ tab, but does show in ‘all’, the user is missing permission. If the icon does not show at all, try refreshing the browser.
You may have a local firewall which is blocking outbound communication. See ‘Firewall Configuration‘. Check the connector logs (on Windows, using EventViewer, on Linux typically with journalctl -fu agilicus-agent)

Web Application Setup

If you have an application hosted on a Subfolder/path in your Web Server You may have an application hosted under a subfolder/path on your web server, possibly because it is better than having another server for it. For example: localhost:port/subpath, localhost:port/support etc. To enable the subpath hosting for your application, 1. Go to Resources > Applications > Define and select the application from the drop down at the top of the page 2. Then in Security (tab) > Firewall Rules > HTTP Rules, change the / entry under path to your custom subpath (For example, /subpath) 3. Under Proxy (tab) > HTTP Rewrites, inside the Common Path Prefix field, enter your custom subpath again (For example, /subpath)

Connector Debugging

Go to the Connector->Overview screen. Your connectors will shortly begin to publish statistics. You can see a summary
of successful/failed connections in the overview table. Click Actions -> View Detailed Statistics for a breakdown of these stats.
Go to the Connector->Overview screen. Each connector reports an overview status here. “Good” means all instances of the connector are running, and that they are fully connected to Agilicus.
As part of maintaining its connection to Agilicus, the connector reports some system information. In the Connector->Overview screen, click on the connector in which you are interested. The resulting expanded table shows each instance of the connector and the hostname of the machine on which it is running.
Yes. First, you need to enable connector logging in Organisation -> Audit Destinations by clicking the Access and Authorization check-boxes. Your connectors will shortly start streaming their logs to Agilicus. You can see the logs in Applications->Diagnose. Fill in the time range you are interested in, then click View Logs. Note that you may see other logs related to your Organisation here. The relevant ones will have source_type equal to agent-connector
No it does not. However, given that it will use TCP/IP to connect to them, it needs to be able to route to the IP it determines for the network, and any firewalls in between must allow access to that IP and the target TCP port.
When establishing a connection to a Network, the connector first determines an IP with which to communicate with. If an Override IP is present in the Network’s configuration, it will use that. Otherwise, it will use the local system’s DNS configuration to do a DNS lookup of the network’s Hostname. It then establishes a connection to that IP using the local system’s standard TCP/IP stack.
The Agilicus Connector supports running in an Active/Active mode, with up to four instances running at a time. Note that if the Connector exposes a Share, then it cannot run in Active/Active mode. Instead, consider an approach like a Agilicus Connector Windows Cluster.
Your Network for the HTTP server may be incorrectly configured. The connector proxies HTTP requests at the application layer. If the HTTP server runs HTTPS/TLS, the Network must be configured to initiate an HTTPS/TLS connection, and it must trust the certificate presented by the server. Conversely, if the HTTP server is plaintext (unencrypted), but the connector is configured to expect TLS, it will fail to establish the connection.

Desktops

TightVNC allows two mechanisms for multiple monitor support.

TightVNC via command line allows specifying the specific display adapter number.

TIghtVNC also allows display offsets in the ‘Extra Ports’ configuration. By specifying a specific port (eg. 5091), a display offset can be configured for a monitor. Once the port is configured and known, a new desktop can be configured in the Agilicus Admin portal with the port number.

Connector Installation

Accurate globally synced time is critical to the proper operation of many modern cryptographic tools. It affects certificte allocation/revocation, sign-in audit logs, etc. See https://www.agilicus.com/product-guide/time-synchronisation/ for further details to ensure the local machine time synchronization is setup.
The Agilicus Connector runs as a Windows Service. Open the Windows ‘Services’ app and look for ‘Agilicus Connector’. The ‘Service Status’ will show the current status.
The connector status can be found by checking the systemctl service status:
$ sudo systemctl status agilicus-agent
Connector logs on Windows can be found in the Windows Event Viewer. Inside Event Viewer (Local) -> Windows Logs -> Application, See “Agilicus Connector – Microsoft Windows“.
Connector logs on Linux are via journalctl -fu agilicus-agent
Navigate to your organisations Agilicus Admin console. Under Resources -> Connectors -> Overview, the column named ‘Status’ reflects the real-time status of the connector.