The following conditions apply to network interfaces, which must be configured before installing Tachyon on a server.
Each network interface must be assigned a static IP Address. Tachyon Setup supports installation using IPv4.
The table below summarizes the network interface requirements for a Response Stack's database and Switches, where n is the number of Switches on the server up to a maximum of five. For the remote SQL Server requirement, please refer to Preparation: Configuring a persistent route for SQL traffic. However please ensure you also consult your server, firewall and networking teams.
A Background Channel is normally installed on the same server as Switches so that devices can connect to both using the same DNS Name FQDN.
The computername of a Tachyon Server must comply with Microsoft NetBIOS naming standards, which includes having a length of 15 characters or less.
Microsoft's guidance can be found here: https://docs.microsoft.com/en-us/windows/desktop/SysInfo/computer-names.
Each server that has Tachyon Server components installed requires its own DNS Name. The Master Stack enables Tachyon users, approvers and administrators to connect to the Tachyon Portal, therefore, it helps users if it has a recognizable and convenient DNS Name such as tachyon.
Tachyon Agents need to connect to Switches and the Background Channel using a DNS Name FQDN defined in the Agent's configuration file. A single-server installation only needs one DNS Name. A Master Stack and Response Stack can only share the same DNS Name if both are installed on the same server. If the server has multiple Switches, and therefore multiple network interfaces, then the same DNS Name can be shared by all Switches, the Background Channel and Master Stack.
The same DNS Name would be used by all the Switches on a Response Stack, but it can also be shared across multiple Response Stacks provided the Name is not also shared with the Master Stack. For this reason, a datacenter serving more than 300000 devices would have two Response Stack servers using the same DNS Name (eg. tachyonrs), and a dedicated Master Stack server using a different DNS Name (eg. tachyon).
A DMZ Server is a special case which needs two DNS Names, an internal DNS Name for the internal network interface, and an external facing DNS Name which may be shared by multiple external facing Switch network interfaces.
Each DNS Name used to access a Tachyon Server must be included as DNS Names in the Subject Alternate Name (SAN) entry of the web server certificate, and the Switch certificate files.
Each DNS Name used to access a Tachyon Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the Tachyon Server service account in Active Directory. This allows Tachyon web applications that use Windows Authentication to authenticate clients.
The following roles, role services and features must be installed/enabled as a minimum.
The Name column is the reference used in PowerShell commands; and for .NET Framework 4.X features the PowerShell name includes 45 instead of the actual version.
Items in bold are included in the PowerShell script available for download from Preparation: Windows Server roles and features.
The following roles, role services and features should be removed/disabled.
Requirements for SQL Server are covered in other sections on this page:
A Tachyon user can be either a domain account or a security group.
Access to Tachyon features can be controlled in Tachyon Admin portal Permissions page as follows:
Tachyon is able to operate in a multi-domain, multi-forest environment. If multiple forests are used then ensure trusts are in place that ensure all in-scope user accounts and groups are present in the Global Catalog of the forest in which the Tachyon Server resides. You have a choice of how Tachyon queries Active Directory, specified during installation.
Tachyon Server uses the following accounts for Windows services::
Tachyon Server uses the following accounts for website application pool identities:
The 1E Catalog Update Service account has the following requirements:
All Tachyon users require accounts in Active Directory. AD accounts must have their userPrincipalName (UPN) attribute populated. This is normal, but may be missing if users accounts have been created using scripts.
Tachyon users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-factor Authentication is enabled.
Users are added to the Tachyon system and assigned roles by a Tachyon Security administrator using the Tachyon Explorer Admin portal.
Please refer to the Users page for an explanation of how to add users to the Tachyon system.
Tachyon does not require any Active Directory security groups, however assigning AD security groups to System Roles is strongly recommended, and for any custom roles as explained in the Roles page. This is especially useful for the Server installation account which is a system role that cannot be modified. If the installation account needs additional roles then these can be assigned to an AD security group.
An AD security group is also useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog.
|AD Distribution groups are not supported. An AD security group can be configured with an email address. Tachyon will use the email address of an AD security group if it has been configured, and relies on the Mail system to forward emails to the members of the AD security group. If the AD security group does not have an email address then Tachyon will send an email to each member that has an email address.|
The Tachyon software must be installed on a Windows Server that is part of an Active Directory domain. Companies do not always have their on-premises Active Directory extended into their cloud environment - there are security concerns that must be taken into account and there must be some mechanism for either a secure network connection between the customer's on-premises systems and the cloud environment (usually via VPN connection) or a way of synchronizing the cloud based Active Directory implementation with the on-premises one (through a directory synchronization of some sort).
Both AWS and Azure provide the following 'cloud' based versions of Active Directory:
AWS Directory Service for Microsoft Active Directory (Enterprise Edition) - This is a full implementation of Active Directory, but it requires a VPN and a trust relationship set up with any existing on-premises Active Directory to be able to use on-premises based accounts. This makes it quite a complex solution to implement and maintain.
1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.
AWS AD Connector - This is a mechanism for redirecting domain queries from the local network to an on-premises Domain Controller using a VPN instead of needing a domain controller in the cloud.
1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.
AWS Simple AD - This is an implementation of Active Directory based upon Samba 4 and provides a limited subset of a full Active Directory.
1E do not support Tachyon running in this environment.
Azure Active Directory Services - This provides the ability to domain join Azure Virtual Machines to your Azure Active Directory, however it is not a full AD as you cannot have domain admin or enterprise admin privileges.
1E do not support Tachyon running in this environment.
The following is the only cloud solution that is fully supported by 1E, and is what we call Extended AD. It doesn't use any of the above, but has the following requirements, which provide an Active Directory presence in the cloud and brings the full capabilities of Active Directory to bear.
1E fully support the Extended AD solution for AWS and Azure, which do not change any of the Active Directory requirements described above.
This is the account used to run Tachyon Setup (and the MSI installer) when installing or upgrading a Tachyon Server. The account is automatically defined as a Tachyon admin user with limited rights which cannot be edited. If you need this account to have additional Tachyon roles, then you will need to use an AD Security Group instead. The installation account has sufficient rights to add other Tachyon users, assign them to Tachyon roles, including the Permissions Administrator role, which should then be used for ongoing use and management of Tachyon.
The server installation account has the following requirements on the server.
The server installation account requires SQL permissions during installation and upgrade, which can be temporary or permanent. The level of SQL permissions depends on the following:
The server installation account has the following rights as a Tachyon user, configured during installation of the Tachyon Server.
|Tachyon Server web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE. This version of Tachyon does not support using a domain user account.|
The SQL Login that is used by the Tachyon Server web applications and services depends on whether the SQL Server is remote from the Tachyon Server or is local, as described in the following table:
During installation, the Tachyon Server installer will always attempt to create the SQL Login and grant it db_owner permission on each of the Tachyon databases.
To replace db_owner with lower permissions based on least privilege, please refer to Tachyon Server post-installation tasks: Replace db_owner.
1E will provide you with a Tachyon.lic license file that defines the products and features your Tachyon System is able to use, for how long, and how many devices it supports, this may be an evaluation or subscription license.
For details of what the license file needs to contain, please refer to Design Considerations: License requirements for consumer applications.
The Tachyon license must be validated on a regular basis via internet contact with the 1E license service, which needs to be whitelisted in your organization - so that it's accessible during setup and running of Tachyon. The regular validation period is set when the license is requested.
For whitelisting purposes, the Tachyon Server (specifically the Coordinator Workflow module in the Master Stack) requires an Internet connection to the 1E license service, as defined in the license file itself. If activation fails, then the system will install but not be usable until activation is completed.
For guidance on whitelisting and configuring Internet Explorer proxy settings, please refer to Preparation: Whitelisting for license activation and validation.
Each server that has Tachyon Server components installed requires its own Web Server certificate (with the exception of a remote SQL Server). This certificate is also used by the Tachyon Switch, therefore a single-server installation requires only one Web Server certificate. This certificate must be provided prior to installation of Tachyon on the server.
The Web Server certificate requires the minimum of the following:
The following need to be considered when requesting this type of certificate.
If you have a Microsoft CA then it is simplest to use the Certificate Enrollment wizard available in the mmc certificates snap-in, to request a Web Server certificate and fill in the details.
Example certificate request (using Option 2 type certificate)
Each device requires a certificate with the following properties, in order for the Tachyon Agent to be authenticated by the Tachyon Switch.
The Agent device's certificate is stored differently depending on the type of OS.
If using a Microsoft Enterprise CA then the following should be considered.
If using a standalone CA, then certificates must be deployed by other means.
If you want to develop your own custom Tachyon instructions, or modify those of other authors, then you will need to sign them using your own code signing certificate so that they can be licensed, imported and run in your Tachyon system. You don't need to do this for instructions that are provided with the product or that have been downloaded from the Tachyon Exchange as they've already been code signed and licensed using the Platform and Exchange certificates from 1E.
Ideally all of your Tachyon instruction developers should share a single code signing certificate between them. Each code signing certificate must be registered in your Tachyon license and associated with your organisations instruction name prefix. When you have chosen your prefix and have your code signing certificate(s) you then need to send details of these to 1E, who will update your Tachyon license. This will then automatically activate on your Tachyon Server (assuming it has connection to the Internet).
The following points apply to the importing and running of custom Tachyon instructions:
Custom Instructions must be signed by the Tachyon Instruction Management Studio (TIMS) using a code-signing certificate present in the Personal certificate store where TIMS is installed (either local user or machine store). The TIMS user signing the Instruction also needs to have access to the certificate's private key.
For a detailed step-by-step process, please refer to Setting up custom Tachyon Instructions for the first time.
On Windows computers, the installation MSIs, executables and DLLs of the Tachyon Server and Agent are digitally signed by 1E using the 1E Limited SHA1 and SHA256 signature certificates.
These signing certificates are issued by the Symantec Class 3 SHA256 Code Signing CA, which in turn is issued by the root CA VeriSign Class 3 Public Primary Certification Authority - G5.
For Tachyon 3.2 and later, the SHA1 and SHA256 signature certificates are each countersigned with the same Timestamp signature certificate:
For Tachyon 3.1, the SHA1 and SHA256 signature certificates are countersigned with different Timestamp signatures:
The root CA certificates (for signing and countersigning) must exist in the Third-Party Root Certification Authorities store (which is replicated in the Trusted Root Certification Authorities store). These root CA certificates are normally automatically provided by Microsoft's Update Root Certificates feature, however for legacy OS computers in a lab environment that are not connected to the Internet, see Constraints of Legacy OS.
Tachyon relies on both client (device) and server side certificates to ensure secure communication. In order for these certificates to work the computers need to trust the PKI implementation (issuing Certification Authority and chain of trust). In a standard on-premises environment devices can be enrolled with certificates using Active Directory Group Policy.
It is possible to use a non-Windows based PKI, but it is then left as an exercise for the user as to how to distribute and enrol device certificates to all end-points.
Given the supported Active Directory configuration above, the PKI requirements described above still apply to a cloud based implementation.
Since clients must be able to access the Tachyon Switch and Background Channel from both the internal corporate network and the Internet, there are some additional considerations when creating the Tachyon web server certificate.
In AWS a standard EC2 instance has an external FQDN based upon its externally accessible IP address. However, this IP address will change each time the server restarts, and since the Tachyon Switch relies on an HTTPS certificate that utilizes the FQDN to authenticate the server, this would cause the Switch to stop working. In order to work around this, any AWS implementation MUST use an Elastic IP address associated with the network interface of the Switch to ensure that the IP address never changes, and therefore the external FQDN is always the same. Alternatively you can create a CNAME entry in your external DNS to point to the external FQDN of the AWS instance and use the CNAME as the subject name of the server certificate.
Clients can be configured to connect to multiple Switches for resilience and geographic load balancing. In many cases a cloud based virtual machine may be able to be accessed through both an internal VPN network, and an external Internet connection. These connections can be made using the same DNS name (via a CNAME entry as specified in the main documentation) or by different DNS names (where there are separate internal and external DNS domains in use).
The certificate crafted for the Tachyon Switch must contain all DNS Names that will be used to contact the server in the Subject Alternate Name (SAN) entry within the certificate.
Any devices that will connect to the Tachyon implementation must have a client certificate from a PKI infrastructure trusted by the Tachyon server. In a Windows domain environment this is usually provided through an Enterprise Certificate Authority and the use of Group Policy. It is also possible to provide certificates through SCEP, which 1E has tested and support the use of the Microsoft Device Enrollment Service (MDES) for this purpose. Use of other SCEP solutions will be supported on a best-efforts basis.
The Tachyon SMTP feature can optionally be enabled to send the following types of emails to Tachyon users.
Emails are HTML format, without any attachments, and have a typical size of approximately 70KB. You can choose to modify the email banner header.
If the Tachyon SMTP feature is enabled, your SMTP relay/gateway may require the following to be configured.
If the Tachyon SMTP feature is enabled, then a Mail-From address is required as the Sender of Tachyon emails.
Tachyon does not require the Mail-From address to belong to a real AD account or have a real mailbox, however your SMTP relay/gateway might have these requirements, therefore you may need to create an additional AD account.
Choose a suitable email address, especially if there is no mailbox, for example email@example.com.
Tachyon users and approvers require email addresses otherwise they will not receive emails when actions require authentication or approval. Email addresses are mandatory if two-factor authentication is enabled.
If an AD Security Group is assigned rights in Tachyon to approve actions, and the Group has an email address, then Tachyon will use that. However, a group member will receive emails only if your organization's mail system supports group emails and the member has an email address. If the Group does not have an email address, then Tachyon will lookup group members and send emails to any member that has an email address. Irrespective of whether the Group has an email address, members must have emails addresses in order to receive emails.
If the 2FA feature is enabled, Tachyon users are prompted to enter a one-time authentication code in addition to their password in order to confirm they want to submit an action instruction.
The one-time authentication code is sent to the user by email. The two-factor authentication feature requires email.
The following tables show the 1E products that combine to support particular features.
Please refer to the relevant connector page to identify security and other requirements for a specific connector.
Patch Success also requires a Tachyon connector.
Product Packs are the means of installing a pack of instructions. Once the instructions are in Tachyon you need to organize them into Instruction Sets which are used as the basis for assigning custom roles that determine who can do what with the instructions in each Set.
You may want to create AD security groups to assign to custom roles instead of assigning users. You should think about groups of people who will view, question, action and approve packs of instructions.
The Export all feature is available on the responses page for a question once it has finished retrieving all its responses. To enable Tachyon users with the appropriate permissions to use this feature you must ensure that the Microsoft Bulk Copy Program (BCP) is installed on the same server where the Tachyon Core has been installed.
Please refer to Tachyon Server post-installation tasks: Configure the Tachyon Server to support the Export all responses feature for more details on configuring SQL BCP and setting up a suitable share.
Nomad integration is available on Windows PC devices and is enabled by default, but can be disabled during installation of the Tachyon Agent.
With the Nomad integration feature enabled, Tachyon Agent will detect if Nomad v6.0.100 or later version is running on the device, and automatically use it to download content from Tachyon Background Channel servers.
Tachyon's use of Nomad works irrespective of whether Nomad is integrated with Configuration Manager or using advanced Nomad features that use ActiveEfficiency.
Configuration Manager is not a prerequisite for Nomad integration with Tachyon, but you will need to consider the following:
Configuration Manager present
You do not need to make any configuration changes to Nomad for it to integrate with Tachyon. Please refer to the Nomad documentation for guidance on designing and deploying Nomad.
Configuration Manager not present
You can deploy Nomad to Windows devices where the Configuration Manager client is not present. You will need to enable the following bits in relevant installer properties:
|Tachyon is able to integrate into the Configuration Manager console to provide a right-click context menu that can be invoked from Configuration Manager computer collections. Tachyon can then use the members of the computer collections as the coverage for any Tachyon instruction selected from the menu. The Configuration Manager extensions are part of the Tachyon Toolkit. For more details please refer to Configuring the Tachyon Configuration Manager console extensions.|
Tachyon Agent language SCALE directly supports running PowerShell on Windows and bash on non-Windows devices, which can be scripts that must be downloaded by SCALE when an instruction runs, or actual command text. You will very probably want to use this feature in your own instructions and ones that you download from 1E. Therefore you must ensure the appropriate scripting environment is present on Agent devices.
The table below shows platform requirements for accessing the Tachyon Portal.
The Verifying page provides detailed steps for verifying a new or upgraded infrastructure, including firsts steps for uploading and running instructions. Below is a list of requirements to perform verification testing.