Skip to main content

MindLink on AWS

Overview​

MindLink is an ultra-secure and mission-focused collaboration platform designed for classified communications at SECRET and above.

MindLink offers mission-approved chat systems meeting strict requirements set by the global intelligence community. MindLink supports real-time coordination and collaboration and enables users to absorb and dissect high volumes of important information while ensuring messaging compliance, and managed user access and data privacy between users, teams and external coalition partners.

Use cases​

MindLink is the go-to multinational, multi-tenant, coalition chat tool on the TS/SCI fabric. As one of few tools capable of meeting stringent security requirements it is the only known Int. B and Int. C accredited chat service for exceptionally controlled information (ECI) approved by data owners. An estimate of MindLink’s current deployments, at the TS/SCI-level, include instantiations in 30+ individual FVEY and U.S. intelligence and defense communities; dozens of multilateral and bilateral chat services between 1st, 2nd, and 3rd parties; and is the collaboration chat service of choice across the UK’s intelligence and defense communities.

Secure chat for enclaves in S+ communities​

MindLink can be deployed to provide secure, compliant messaging for mission enclaves in SECRET and above environments. MindLink's light-weight dependencies and flexible deployment options mean that you can spin up an instance quickly for a small number of users, or scale out to support thousands of users.

Secure chat as a service provided by a service provider for multiple organizations​

MindLink can be deployed to provide a centralized chat service for multiple organizations, such as for a government national service provider.

MindLink enables inter-organizational collaboration with full Attribute-Based Access Controls (ABAC) and Enterprise End-to-End Encryption (EE2EE) capabilities. On a single infrastructure instantiation, it allows multiple tenant organizations on the system to collaborate with approved coalition partners. To ensure the privacy of coalitions and their members, MindLink introduces a strict, deep, attribute and classification/clearance-based ethical wall using a secure communities architecture. In effect, it separates tenants that are not permitted to know about, or interact with each other, on the same MindLink instantiation.

Secure chat for C4ISR in low bandwidth edge scenarios​

MindLink's lightweight client is capable of successfully providing connected chat services to edge locations that have low bandwidth or intermittent connectivity, such as a ship or aircraft. This enables MindLink to be used to enhance command and control across an active mission theatre involving land, sea, and air assets.

Architecture overview​

The most basic deployment runs both front end and back end services in a single process and you can form a cluster of these one-box deployments for high availability and resiliency.

This document will guide you through deploying the following topology:

Clustered MindLink Deployment Figure 1 - Clustered MindLink deployment in AWS.

As shown in Figure 1, this guide sets up the following:

  • A highly available architecture that spans three Availability Zones.
  • A VPC configured with private subnets according to AWS best practices, to provide you with your own virtual network on AWS.
  • An Elastic Load Balancer to distribute traffic among MindLink nodes in the private subnets.
  • An internet gateway for exposing MindLink to end users (this is optional, if you are deploying to local private networks a transit gateway can be used instead).

In the public subnets:

  • A private Network Address Translation gateway

In the private subnets:

  • MindLink server nodes deployed to Amazon Elastic Compute Cloud (Amazon EC2) instances. You can choose to deploy 3, 5, 7+ server nodes (3 shown).

We assume that you already have the required dependencies deployed and can make them accessible to the private subnets:

  • Microsoft Active Directory infrastructure
  • Microsoft SQL Server 2019 cluster
  • An Attribute Server

Architecture details​

Installer​

The MindLink solution is delivered as a single installable artifact, MindLink-Anywhere-vX.msi that can be downloaded by getting in touch with us at product@mindlinksoft.com.

The installation follows the standard Microsoft Windows Installer experience and installs a configuration application, the "MindLink Anywhere Management Center", and a Windows service, the "MindLink Anywhere Server".

Exposed endpoints​

The solution exposes a single HTTPS endpoint (by default on port 9080) that needs to be exposed to end users.

Additional endpoints that do not need to be exposed to end users include:

  • Health probe endpoint (by default on port 9007)

AWS services in this solution​

Supporting AWS services
Amazon Virtual Private Cloud (VPC)
AWS Backup
AWS Budgets
AWS Organizations
AWS IAM
AWS Application Load Balancer
AWS EC2

Information security​

MindLink stores all data within a Microsoft SQL Server database, and we recommend using SQL Always Encrypted to protect sensitive columns from insider threat.

See the documentation on encryption at rest for a detailed explanation.

If you are looking to deploy Enterprise End to End Encryption (EE2EE), you will need some additional dependencies and configuration described at end to end encryption.

MindLink additionally stores files and user preferences on a network file share. We recommend restricting access to the file share to the service, and enable file system encryption.

Plan your deployment​

This section describes the sizing, cost, security, Region and quota considerations for planning your deployment.

Sizing​

The minimum system requirements for MindLink are:

Hardware requirementsSoftware requirements
Quad core, 64-bit CPU (minimum 2.4 GHz)Windows Server 2019 / 2022
Gigabit Ethernet connectionMicrosoft .NET 8.0 Desktop Runtime and Microsoft .NET 8.0 ASP.NET Core Runtime
8GB RAMDomain joined
Minimum 1Gb disk space

This translates to running on the following EC2 families:

  • m5n
  • m5
  • m6a
  • m6in
  • m7a
  • m7i

You should select an instance size of xlarge or greater.

success

For best performance and larger workloads, prefer larger instances and fewer nodes, i.e., scale vertically first, and scale horizontally for resilience, and cost management.

Cost​

The MindLink solution is priced using a per-user subscription model.

TierPrice per user per year
Business (99 users or less)$168
Business BundleGenerous bundle discounts are available at 100, 200, 500, 1000 user milestones.
EnterpriseGet in contact with sales@mindlinksoft.com to discuss your needs.

AWS Cost​

You are responsible for the cost of the AWS services used while running this solution.

We recommend creating a budget to help manage costs.

For full details, refer to the pricing for each AWS service used in this solution.

Sample cost table​

The following table provides a sample cost breakdown for deploying MindLink in N. Virginia, with no activity, for one month.

AWS ServiceDimensionsMonthly cost
Amazon VPC3 private subnets and 3 availability zones at 3GB each month.$142.23
Amazon EC23 m5n.xlarge$924.18
AWS Elastic Load Balancing1 application load balancer$16.43
info

Amazon EC2 instance cost does not change as activity increases - instances are either running, or not. You could deploy an auto-scaling pool to automatically adjust the number of running instances to reduce costs during periods of lower activity.

Data transfer is priced at the Free Tier or less than $0.01 each month.

Supported AWS regions​

MindLink can be deployed wherever AWS supports EC2 instances, however, we recommend deploying in environments where the Landing Zone Accelerator has been implemented, for further information refer to LZA supported regions.

For the most current availability of AWS services by Region, refer to the AWS Regional Services List.

Quotas​

Service quotas are the maximum number of resources or operations for your AWS account. Make sure that you have sufficient quota for each of the services implemented in this solution. For more information see AWS service quotas.

Primarily, you will need to ensure that your EC2 quota enables you to deploy the number of MindLink nodes that you wish to deploy. However, you will need to consider the quotas of the other AWS services implemented in this solution.

Deployment options​

MindLink can be deployed in multiple configurations, according to the required support and the available topology.

Please note that currently MindLink chat rooms can only be accessed and used via a product of the MindLink suite, either client (Anywhere, Desktop, Mobile) or integration (MLAPI). Third party clients will not be able to interact with MindLink rooms.

MindLink is shipped as a horizontally scalable modular monolith and is split into two application roles:

  1. The front end services - serving as the gateway for MindLink clients
  2. The back end services - hosting the MindLink Chat Engine

You may deploy MindLink as a single tier cluster, or as two independent clustered tiers (one frontend and one backend).

Networking​

The recommended deployment of MindLink requires the setup of the following networking components:

  1. A Virtual Private Cloud to contain all MindLink server instances.
  2. An Elastic Application Load balancer to distribute load across the MindLink servers.
  3. 3 Availability Zones to contain one or more MindLink servers.
  4. A public subnet per availability zone to provide routing from the Load Balancer to the MindLink server, and to provide routing from the MindLink server to external dependencies.
  5. A private subnet per availability zone to contain one or more MindLink servers.

MindLink servers require the following ports for communication, the routing rules from the private subnet of the MindLink servers must be configured to support these endpoint connections:

PortProtocolDirectionPurposeRoute
9080HTTPSInboundServes the MindLink client assets and API surfacePublic via the Load Balancer
30000TLSInbound/OutboundCluster gateway to cluster clients (other MindLink servers)Internal private subnet -> private subnet
11111TLSInbound/OutboundCluster silo to cluster silo (other MindLink servers forming the MindLink cluster)Internal private subnet -> private subnet
389LDAPSOutboundLDAP connection to Active Directory.Internal private subnet -> Active Directory server
443HTTPSOutboundHTTP connection to Attribute Server.Internal private subnet -> Attribute server
1433SQL/TLSOutboundSQL connection to Microsoft SQL Server.Internal private subnet -> Microsoft SQL Server

Mandatory accounts​

First and foremost, you must adopt a principal of least privilege approach to resource management. This means granting accounts the minimum permissions required to perform a task, it is also advisable to separate permissions across multiple accounts (and people) to narrow the permissions for any one account.

  1. AWSAccount - You need to have a root AWS account in which resources are created.
  2. You need to have AWS IAM users and/or groups for managing AWS resources:
    • VPCAdmin - Permission to create and manage Virtual Private Cloud instances
    • NetworkAdmin - Permission to create network resources and confige routing
    • EC2Admin - Permission to create and manage EC2 instances
    • LBAdmin - Permission to create and manage Elastic Application Load Balancers
  3. You need to have Active Directory users and/or groups for managing:
    • DomainAdmin - Domain administrator with permission to manage domain users and computers
    • SQLAdmin - SQL Server Administrator with permission to create databases and database users
    • CertificateAdmin - Certificate administrator with permission to create and distribute trusted certificates
    • LocalAdmin - Operating System local administrator with permission to manage machine configuration
    • MindLinkAdmin - MindLink service administrator with permission to manage the MindLink application server
  4. MindLinkServiceAccount - You need to have an Active Directory account for the MindLink Service, with permissions to:
    • Read/write to the MindLink SQL Database
    • Read the service certificates
    • Read/write to the network file share for files and user preferences
  5. MindLinkUserAccount - You need to have Active Directory users representing MindLink end users
warning

Do not use your AWS root account to create AWS resources, you must use a suitable IAM user account.

Application dependencies​

The following applications, platforms, and services need to exist and be reachable from the subnets in which the MindLink servers will be deployed:

  1. Microsoft Active Directory
    • MindLink requires being joined to a Microsoft Active Directory domain
  2. Microsoft SQL Server 2016+
    • MindLink requires a Microsoft SQL Server 2016+
    • We recommend using an Always On Availability Group for high availability
  3. A network attached storage device that is exposed as a Windows File Share
  4. A corporate attribute server
    • MindLink leverages a pluggable attribute service, get in contact directly with product@mindlinksoft.com to understand whether your attribute service is already supported.

Deploy the solution​

info

Provided that you have the required dependencies, a complete deployment, including all pre-deployment, deployment, and post-deployment steps should take between 3-6 hours.

Pre-deployment steps​

1. Create AWS IAM users for managing required AWS resources​

Consult the AWS guidance on creating IAM user accounts and assigning permissions TODO. Ideally, following the principle of least privilege, you would have IAM accounts for each separate resource.

  • Virtual Private Cloud administrator [VPCAdmin] with permission to create and manage a Virtual Private Cloud.
  • Network administrator [NetworkAdmin] with permission to create and manage networks and routing rules.
  • EC2 administrator [EC2Admin] with permission to create and manage EC2 instances.
  • Elastic Load Balancer administrator [LBAdmin] with permission to create and manage Elastic Load Balancer instances.

2. Create Active Directory users for managing domain resources​

Consult Microsoft guidance on creating Active Directory user accounts and assigning permissions. Ideally, following the principle of least privilege, you would have Active Directory administrator accounts for each separate resource.

  • Domain administrator [DomainAdmin] will already exist, and should have permission to create and manage user accounts and join machines to the domain.
  • SQL Server administrator [SQLAdmin] with permission to create and manage SQL Server databases.
  • Certificate administrator [CertificateAdmin] with permission to issue machine certificates.
  • Operating system local administrator [LocalAdmin] with permission to install Windows Services and modify local system configuration.
  • MindLink service administrator [MindLinkAdmin] who will be granted permission to administer the MindLink application service.
  • MindLink service account [MindLinkServiceAccount] with permission to run as a Windows service.

3. Create the Virtual Private Cloud​

info

Skip this step if you are deploying MindLink into an existing Virtual Private Cloud.

The VPCAdmin must create a new Virtual Private Cloud according to the AWS documentation.

4. Create the network architecture​

info

Skip this step if you are deploying MindLink into existing subnets and network topology.

The NetworkAdmin must create new private subnets across multiple availability zones, we recommend one availability zone per MindLink server, up to 3 servers, and then the number of availability zones you distribute over is flexible based on your availability needs.

5. Create the EC2 instances​

The EC2Admin must create a new Windows Server 2022 EC2 instance for each MindLink server being deployed. Make sure to distribute the EC2 instances across the availability zones. See getting started with Windows EC2 instances for guidance.

6. Domain join EC2 instances​

The DomainAdmin must domain join the machines to the Active Directory domain.

The DatabaseAdmin must create a new MindLink database that spans an SQL Server Always On Availability Group. The DatabaseAdmin must give the MindLinkServiceAccount permissions to read and write database tables and records.

8. Create and assign machine certificates​

The CertificateAdmin must create new MindLink service certificates for the following:

  • A Web Server certificate for each MindLink server, including the identity the server will present to the load balancer as a SAN.
  • A token signing certificate, shared across all MindLink servers.
  • A cluster certificate for each MindLink server, including the identity of the cluster in the domain.

Each of these certificates must be installed on the MindLink servers, and the private key permissions assigned to the MindLinkServiceAccount.

Deployment steps​

As the LocalAdmin, install MindLink onto each MindLink server, ensuring that it is configured to run as the MindLinkServiceAccount.

Once installed, use the MindLink Management Center to configure each MindLink server by following the MCE standalone configuration guide.

info

Make sure that you use the database, certificates, and credentials created during the pre-deployment steps.

3. Create the Elastic Application Load Balancer​

Follow the guidance in AWS elastic load balancing documentation to deploy an application load balancer that targets the MindLink server EC2 instances you created previously.

info

MindLink requires sticky sessions (session affinity) to be configured, see AWS Elastic load balancing sticky sessions.

Post-deployment steps​

Once the service is up and running, you will want to:

  1. Connect an administrative session,
  2. Add users to the MCE system,
  3. Create Security Contexts that define boundaries of communication,
  4. Log on and create rooms to test the required capabilities are functioning.

The first step to performing administrative function is to connect to the MindLink cluster via the administration PowerShell module.

  1. On one of the MindLink server instances, open a new PowerShell session as the MindLinkAdmin account.
  2. Import the MCE PowerShell module 
    Import-Module MceAdmin
  3. Connect to the MindLink cluster 
    Connect-MceSession -ServerAddress "https://<instance>:9080"

The prompt should return no errors, indicating that a session has been established.

The easiest way to add users to MindLink is to use the Active Directory PowerShell module.

MindLink synchronizes user attributes from Active Directory and uses the objectGUID of the Active Directory User object to enable a user. To make life simpler, the commandlet accepts a pipelined input from the AD PowerShell module:

Get-AdUser -Filter * -SearchBase "OU=MindLinkUsers,DC=domain,DC=local" | New-MceUser -IsEnabled $true

MindLink Security Contexts leverage Attribute Based Access control to determine user membership. All chat rooms within MindLink must be created within one or more Security Contexts and define a top-level security boundary for the rooms.

You can create a Security Context using the New-MceSecurityContext commandlet, as described in the New-MceSecurityContext documentation.

4. Log on and create chat rooms​

To test that the configuration is working as expected, you will need to log a user into MindLink and try out the functionality.

  1. Navigate to the public address of the Elastic Application Load Balancer for the MindLink service, e.g. https://mindlink.company.com.
  2. Log on using the credentials of a test user you enabled in step 2.
  3. Create a chat room within the MindLink interface Profile > Manage Groups > Create Group.
  4. Join the chat room within the MindLink interface by searching for it in the dock.
  5. Test sending messages.

Update process​

If you have previously deployed this solution, follow this procedure to update MindLink. This procedure requires a period of "down time" to the solution while the upgrade is in progress.

The update process will take a server offline, update it and leave it offline until all servers are offline and updated. Then an updated server will be brought online, verified, and followed by bring each remaining server online.

  1. Take one server offline and run the latest installer to upgrade in-place.

  2. Run the MindLink Management Center and update the configuration according to the release and feature documentation for the new version.

  3. Repeat steps 1-2 for all remaining servers.

  4. At this stage, verify that all servers are offline.

  5. Start up one updated server.

  6. Perform any post-deployment migration steps as described in the release documentation for the new version.

  7. Verify the updated server is working as expected.

  8. Start up the remaining servers.

Troubleshooting​

Problem: Configuration warnings when saving configuration​

When running the MindLink Management Center, saving configuration will check that the provided values are valid. The tool will complain when saving the configuration if there is something that does not appear valid. You should address the guidance provided by the Management Center, as ignoring the validation error will result in the service being unable to start.

Problem: The database cannot be installed​

When using the MindLink Management Center to install or upgrade the database, you encounter an error that the database could not be installed (or upgraded).

Permission error​

You might receive an error explaining that the account does not have permission.

Resolution​

Try to run the install/upgrade again by using the credential override functionality in the MindLink Management Center to run with an account that has database owner permissions.

Connectivity error​

You might receive an error explaining that the database could not be reached.

Resolution​

Ensure that the database connection string is correct, that the database server is operational, and that the account running the Management Center has permissions to the database.

To resolve this issue you will need to consult the service logs. The most likely causes and resolutions are provided here, if further assistance is needed reach out to our support team.

Invalid configuration version​

This is caused by performing a recent upgrade without first running the MindLink Management Center to upgrade configuration.

Resolution​

Run the MindLink Management Center and save the configuration, even if there are no required changes reported. When new optional features are introduced, the Management Center will not flag validation errors for the new configuration, but you will need to save the configuration for the service to function correctly.

Configuration validation error​

This is caused by saving a configuration that is invalid.

Resolution​

Run the MindLink Management Center and address the validation errors it reports, then save the configuration and restart the service.

Database connectivity error​

This is caused by an error in communicating with the database.

Resolution​

Check that the database connection string is correct, that the database server is operational, and that the service account has permission to access the database.

Database requires upgrade​

This is caused by performing a recent upgrade without upgrading the MindLink database before starting the service.

Resolution​
  1. Run the MindLink Management Center and navigate to the respective database configuration page (MCE, and/or Group Aliases).
  2. Click on "Test database".
  3. The result should indicate that a database upgrade is required, you can either use the Management Center to upgrade the database, or generate the required SQL script to run manually.

There can be many potential reasons why the user cannot log on, check the MindLink server logs for more details. Some common errors are provided here.

Credentials are invalid​

This can have multiple causes, the MindLink server logs will provide more details on which stage of authentication and authorization failed.

Resolution​
  1. Ensure the user has entered the correct credentials.
  2. Ensure that the user is registered in MindLink (Get-MceUser commandlet), if not, use the New-MceUser commandlet to create them.
  3. Ensure that the user's attributes have synchronized (Get-MceUserAttributeSynchronizateState), if not, sync the user's attributes using the Sync-MceUserAttributes commandlet.
  4. Ensure that the user's attributes give them the required level of clearance for the MindLink server, the required level of clearance is configured via the MindLink Management Center.

MindLink user attributes may fail to synchronize for a variety of reasons, check the MindLink server logs for more details. Some common errors are provided here.

Certificate validation failed​

MindLink authenticates to the attribute server using certificate-based authentication. Make sure that you have selected the correct certificate to identify MindLink to the attribute server and given the MindLinkServiceAccount permission to the private key.

User not found​

MindLink queries for user attributes using a configurable identity source, make sure that you have selected the correct identity source for your attribute server. by default MindLink will use an identity source registered in the Active Directory altSecurityIdentities property to query the attribute server.

Health monitoring​

Health probe​

The MindLink server provides a simple health probe endpoint that is configurable through the MindLink Management Center (default port 9007).

success

Use the default endpoint address http://<ec2-instance-dns-name>:9007/InfoService/Status as the health probe target for the AWS Elastic Application Load Balancer.

Cluster dashboard​

The MindLink server exposes an optional dashboard to view the health of the backend cluster, the endpoint is configurable through the MindLink Management Center MCE configuration page.

For more details on the dashboard, see Monitoring MCE.

success

Browse to the default endpoint address http://<ec2-instance-dns-name>:8082 to see the cluster dashboard.

Logs​

The MindLink server provides extensive logs and uses a flexible logging framework, Serilog, so that you can configure different log targets for different logging events. See logging guidance for further details.

Distributed logging and tracing​

For more advanced scenarios, MindLink also supports distributed logging and tracing using Open Telemetry. See distributed logging and tracing for further details.

Backup and recovery​

There are 3 aspects of the MindLink deployment that need to be considered for backups:

  1. The MindLink server configuration
  2. The MindLink database
  3. Network storage for MindLink file uploads and user preferences
  1. Navigate to C:/Program Files/MindLink Software/MindLink Anywhere/ManagementTool
  2. Make a backup of staging.config
  1. Copy your backup staging.config file to C:/Program Files/MindLink Software/MindLink Anywhere/ManagementTool
  2. Run the MindLink Management Center and save changes

Use your preferred Microsoft SQL Server database backup and restore procedure, more details can be found at Microsoft Learn SQL Server backup and restore databases.

You should follow guidance on how to backup your chosen file storage solution.

For standard Windows server file shares, you will need to periodically back up the content of the file share to long term storage. Restoring is a matter of copying the contents of the backup to the file share.

Optional: Backup EC2 instances​

An alternative approach to backing up MindLink server configuration (and files) independently is to backup the EC2 instance itself using AWS Backup.

Maintenance​

Rotating service credentials​

Rotating service credentials requires modifying the service account credentials on the MindLink Anywhere Server Windows Service and restarting the service.

caution

If you are changing the service account, and not just the password, you will need to ensure that the new service account has permissions to the configured file shares, certificates, and databases.

Rotating certificates​

Rotating certificates requires manually reconfiguring each MindLink server to use the updated certificates via the MindLink Management Center.

Provided the new certificates meet the certificate requirements, you can rotate the certificates one server at a time to minimize downtime.

Managing licenses​

The MindLink server must have a valid license file configured, which is supplied by MindLink and can be obtained by reaching out to product@mindlinksoft.com.

The MindLink Management Center will show the licensed products and license expiration date.

To rotate the license you will need to manually update the license in the MindLink Management Center on each MindLink server instance. To minimize downtime we recommend requesting a new license before your existing license expires, and update licenses one server at a time.

Emergency maintenance​

In the event that the service is unhealthy and troubleshooting has not resolved the issue, or a catastrophic failure has occurred and you need to restore service as soon as possible, you may need to implement an emergency recovery procedure.

  1. Stop all MindLink server instances,
  2. Restore the MindLink database to a known good state
  3. Start a single MindLink server instance ad verify that it is operating correctly,
  4. Start the remaining MindLink server instances and continue monitoring.

It is possible that despite a known good database state, the service is still not healthy. This is most likely due to a recent change in configuration, recovering the MindLink server configuration will resolve any issues in changes to the MindLink server configuration.

If a problem still exists, you will need to identify the core issue by inspecting logs and traces for errors. This will limit the scope of the recovery procedure.

caution

Before performing an emergency recovery, contact support to ensure that there is not an alternative resolution.

Support​

info

For all support queries, reach out to support@mindlinksoft.com.

Support TierOperational hours
Standard9am-5pm, Mon-Fri, UK time
Enterprise24x7x365