Contents
Architecture
Enabling Tachyon to support devices that are external to your company network is done by slightly extending the default single-server architecture.
The Responses Stack handles communications between the Master Stack and the Tachyon clients. The Background Channel and Switches components handle the direct communication with the Tachyon clients, the Core processes the information in both directions between the Master Stack and the Switches.
To enable external Tachyon client devices to interact with Tachyon you need to put the Background Channel and at least one Switch into the DMZ.
Communications ports
The Tachyon communications ports between the Tachyon Master Server and the Tachyon DMZ Server must be opened, as illustrated in the picture shown opposite. Please refer to the Communication Ports page for more details.
Preparation
In the following summary and configuration steps, the following terminology is used:
- Relevant internal servers
- Any internal server which hosts a Tachyon Server component which communicates with any DMZ Server
- Typically this will include the servers which host the Coordinator, the Consumer API, and any Core bound to a DMZ switch that is registered in the dbo.SwitchToCoreApi table in the TachyonMaster database
- The example diagrams and steps refer to only one internal server, but there may be separate servers for Master Stack (with Coordinator and Consumer API) and Response Stack (with Core).
- DMZ Server
- Any server that has Tachyon Server components installed which is not on the internal network (that is, outside of the corporate network)
- This includes a Tachyon DMZ Server (which has one or more Switches and a Background Channel)
You must ensure the following before installation of Tachyon on a DMZ Server.
- The Tachyon Master Server is installed and verified with internal Tachyon clients.
- Please refer to Implementing Tachyon for more details
- The documentation below assumes this has a Master Stack and Response Stack on the same server.
- A Response Stack is required in order to provide the Core component that will be used by the remote DMZ Server. Internal clients are not required to use the Switch and Background Channel of this Response Stack.
- The DMZ internal and external firewall are configured correctly. Please refer to the Communication Ports page for more details.
- The Tachyon DMZ Server is provisioned. Although a DMZ Server does not have all Tachyon components, all prerequisites must be met in order for Tachyon Setup to run. In particular, the following must be prepared before installation. For more detail about each requirement, click on the relevant link.
- Requirements: DNS Names (Preparation: DNS Names)
- The DMZ Server requires two DNS Names, even if the DMZ Server is configured with one network interface. Two network interfaces are required to prevent response traffic from clients to server, and from server to Core, using the same network interface.
- A DMZ Server internal DNS Name so that the internal Tachyon Server can connect to the DMZ Server. Documentation below assumes this DNS Name exists, but it can alternatively be the server's hostname FQDN.
- A DMZ Server external DNS Name so that Internet devices can connect to the DMZ Server, which is the name included in the Tachyon client configuration for Switch and Background Channel settings (1E Client configuration file). This DNS Name is not necessarily for the actual IP Address(es) of the external network interfaces if DMZ firewall, Network Address Translation (NAT) or other routing is employed.
- Both DNS Names must be included in the Web server certificate. Please see Certificate requirements below for more information on certificate DNS Name requirements.
- If DMZ Server is domain-joined, both DNS Names require an HTTP class Service Principal Name (SPN) registered on the DMZ Server's computer$ account. Please refer to Preparation: Service Principal Names for more details.
- Requirements: Network interfaces (Preparation: Network interfaces)
- The DMZ Server should have an internal network interface, and an external network interface for each Switch, in order to keep Core and Switch traffic apart. This recommendation is for performance reasons when supporting over 500 devices.
- If an internal interface is not used, then the external interface will use both DNS Names.
- If using two interfaces...
- the internal interface will use the internal DNS Name, and the external interface(s) will use the external DNS Name. This is the assumption made in the configuration steps below.
- internal and external interfaces will typically be on different subnets.
- ensure your network routing is configured to route outgoing traffic using the internal interface. You may need to configure a persistent route, for example using the same steps described in Preparation: Configuring a persistent route for SQL traffic.
- Requirements: Tachyon Server Certificates (Preparation: Web server certificate)
- Each DMZ Server requires its own web server certificate. Please see Certificate requirements below for more information.
- Requirements: Windows Server roles and features (Preparation: Windows Server roles and features)
- IIS to host the Background Channel application.
- Windows Authentication role if the server is domain joined and has a trust relationship with the domain that the Master Stack is configured to use.
- Requirements: DNS Names (Preparation: DNS Names)
- Test devices with the Tachyon client installed.
- At least one connected to the internal network; another connected to the external network.
Certificate requirements
Tachyon Server certificate requirements are defined in Requirements: Tachyon Server certificates.
Tachyon DMZ Server installations have additional requirements for its certificates.
Relevant internal servers
Type | Additional certificate requirements | Where used |
---|---|---|
Tachyon Server certificate | The server certificate must comply with certificate requirements for standard servers (see above) with the additional requirement of two DNS Names to be present in the certificate to support a remote DMZ Server.
| This is the usual Tachyon website certificate. A DMZ Server installation has additional needs to allow Switches on the DMZ Server to communicate with:
|
Tachyon Consumer API client certificate | The client certificate on the Tachyon Master Stack has the following requirements:
You will need the thumbprint for this certificate. In our example, this is 545EF2AF74201A8CFAE0F0CEFE2D987237AEC176. | Used by the Tachyon Master Stack (Consumer API) to perform client authentication with the Background Channel on the DMZ Server. Required only if certificate authentication is used instead of domain authentication. This certificate is only used if your DMZ Server is not domain-joined, or does not have a two-way trust between your internal domain and your DMZ domain. |
DMZ Server
Type | Additional certificate requirements | Where used |
---|---|---|
DMZ Server certificate | The Certificate requirements for standard servers (see above) requires two DNS Names which must be present in the certificate if the server has multiple IP Addresses. This is a requirement for a DMZ Server. theefore the However, a DMZ Server requires an additional DNS Name separate communications between internal and external Switches: The Certificate requirements for standard servers are valid with regard to trust, usage, enhanced key usage, the private key, and revocation. However, as this is an externally reachable certificate, it is not recommended that the hostname FQDN is present in the certificate. As such, the certificate must meet the following requirements:
Optionally, it may also contain a Subject Common Name Field (subject:commonName) that is unique within the organization that identifies the certificate (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf#page=54). | Used by the Switch(es) and Background Channel to secure communication to Tachyon clients. |
DMZ Server client certificate | The client certificate on the Tachyon DMZ Server has the following requirements:
| Used by Switch(es) to perform client certificate authentication with its assigned Response Stack (Core). |
Certificate trust
The relevant internal servers must trust the DMZ Server certificate(s). In order to do so, ensure the DMZ Server certificate(s)' issuing chain is imported into the Local Machine's Trusted Root Certification Authority or Intermediate Certification Authorities stores (as appropriate) on each relevant internal server.
The DMZ server must trust the relevant internal servers' certificate(s). In order to do so, ensure the relevant internal servers' certificate(s) issuing chain is imported into the Local Machine's Trusted Root Certification Authority and Intermediate Certification Authorities (as appropriate) stores on the DMZ Servers.
The DMZ server must also trust the Tachyon clients' certificates. In order to do so, ensure the relevant clients' certificate(s) issuing chain is imported into the Local Machine's Trusted Root Certification Authority and Intermediate Certification Authorities (as appropriate) stores on the DMZ Servers.
Please note that if any certification authority in this file have a HTTP CDP they must be reachable by the DMZ Server. Further information on this can be found in the note below.
If the certificates on the DMZ Server and the internal Tachyon servers are from different issuing CAs, then:
- Obtain the certificates (public keys only) for all the intermediate CAs, up to and including the Root CA of the internal Tachyon Server's Web Server Certificate, and add them to the corresponding CA stores on the DMZ Server. If you do not do this, the Switch on the DMZ Server will not be able to start because it won't be able to trust the Core API on the relevant internal server.
Similarly, if the certificates on the DMZ Server and client authentication certificates on external Tachyon clients are from different issuing CAs, then:
- Obtain the device's intermediate and root CA certificates, and add them to the corresponding CA stores on the DMZ Server.
- Windows devices will need the Tachyon DMZ Server's intermediate and root CA certificates to be added to their CA stores
- Non-windows devices will need the Tachyon DMZ Server's intermediate and root CA certificates to be added to their cacert.pem file
The installation process for a Tachyon DMZ Server
Overview
The process requires several manual steps before and after running Tachyon Setup, because the automated process is prevented by the DMZ Server not having access to the Tachyon Master database on the internal server. These steps include defining the cfgName used in the SwitchCommandLine for each Switch, which maps to a new row created in the SwitchConfiguration table in the Tachyon Master database. For more details about cfgName please refer to the Switch Command Lines page. In addition, the steps include increasing the level of security by changing the system so that all Switches connect to the Core API using HTTPS instead of HTTP (a remote Core is only accessible via HTTPS). The Background Channel is then initialized before finally carrying out verification steps to ensure everything is working.
One of the steps involves adding a new Background Channel. From that point onwards, you will not be able to update existing Background Channels until you have completed all steps. This means you cannot add or remove any instructions that use resources.
To illustrate the following detailed steps we use the ACME network with two servers.
DNS Names
Use the following table to help map the DNS Names used in your environment with the name used in the steps below.
Server | DNS Name references | DNS Name examples | DNS Names used in your environment |
---|---|---|---|
The internal Tachyon Server The diagram shows only relevant components of the Master Stack and Response Stack | Tachyon Server hostname FQDN | ACME-TCNMST.acme.local | |
Tachyon Server DNS Name FQDN | tachyon.acme.local | ||
Alternate DNS Name FQDN | tachyonalt.acme.local | ||
The external Tachyon DMZ Server | DMZ Server hostname FQDN | ACME-TCNDMZ | |
DMZ Server internal DNS Name FQDN | tachyondmz.acme.local | ||
DMZ Server external DNS Name FQDN (this name is only used by clients and only mentioned in the instructions below when configuring the bindings on the DMZ Server) | tachyon.acme.com |
Detailed steps
Do all the steps if your DMZ Server is not domain-joined, or does not have a two-way trust between your internal domain and your DMZ domain.
Skip the highlighted steps if your DMZ server is domain joined and has a two-way trust between your internal domain and your DMZ domain.
Location | Detailed steps | |
---|---|---|
1 | Internal Tachyon Server (Master and Response Stacks) and internal Tachyon client(s). | Install the internal Tachyon Server, with Master and Response Stacks, and ensure it works by running the tests described in Verifying. |
2 | DMZ Server. | Ensure Preparation steps are complete for the Tachyon DMZ Server. |
3 | Internal Tachyon Server (Master Stack). | On the internal Tachyon Server (Master Stack) Add another HTTPS binding to the Tachyon website. In our example this is https://tachyonalt.acme.local:443 Remember this binding for steps 5, 8 and 21.
|
4 | Internal Tachyon Server (Master Stack). Only when not domain-joined, or is untrusted. Skip this step if domain-joined and trusted. | On the internal Tachyon Server (Master Stack) Ensure the service account used by the Consumer API web application pool has read permission for the Tachyon Consumer API client certificate. By default the service account is Network Service.
|
5 | Internal TachyonMaster database. | In the TachyonMaster database, modify the CoreApiConfiguration table to use HTTPS Core instead of the default HTTP CoreInternal.
|
6 | Internal TachyonMaster database. | In the TachyonMaster database, register each Switch planned for the DMZ Server, even though you have not yet installed the DMZ Server. One Switch will be required for every 50,000 clients connected to the DMZ Server at any one time, up to a maximum of 5 Switches.
|
7 | Internal TachyonMaster database. | In the TachyonMaster database, register the name of each new Background Channel.
|
8 | Internal Tachyon Server (Response Stack). | On the internal Tachyon Server (Response Stack) Modify the existing Switch host configuration file to use the HTTPS binding set up step 3.
If -cfgName is not already present in the SwitchCommandLine, then do not add it, you only need to change the -config value. If you have multiple switches, ensure you modify each SwitchCommandLine.n entry in the configuration file. The command-line will include -IgnoreClientCerts if you unchecked Switches require client certificates to be presented by Tachyon Agents in Tachyon Setup. |
9 | Internal Tachyon Server (Response Stack). | On the internal Tachyon Server (Response Stack) that the DMZ Server will be communicating with, modify the IP Address and Domain Restrictions module in the Tachyon Core web application to enable the IP Address of the DMZ Server internal DNS Name to access the internal Core.
Please refer to Implementation issues: IP address and domain restrictions for more details. This step is only required on the Core web application. It not required on other web applications because they allow communication from any exernal device, by default. On the internal Tachyon Server (Response Stack) open a command prompt and ping the DMZ Server internal DNS Name. In our example this is tachyondmz.acme.local . This should prove that the name is resolved and provide the IP Address, even if you do not get a response because the firewall is blocking ICMP. |
10 | Internal Tachyon Server (Response Stack). | On the internal Tachyon Server (Response Stack), restart all Switches and confirm they are working.
|
11 | Internal Tachyon Server (Master and Response Stacks) and internal Tachyon client(s). | Ensure that everything is still working by running the tests described in Verifying. |
12 | DMZ Server. | On the Tachyon DMZ Server On the Tachyon DMZ Server, run Tachyon Setup and complete the installation using the configuration option DMZ Server. If you are using internal and external network interfaces on the DMZ Server, then ensure you select an external interface IP Address for each Switch in the Switch Configuration screen. The workflow in Tachyon Setup has not yet been optimized for installing just the Switch and Background Channel components (selectable as DMZ Server). Specifically:
You will manually add the binding for the client (external) DNS Name in the next step. |
13 | DMZ Server. | After installation, on the Tachyon DMZ Server, add an additional HTTPS binding for external client devices to use.
|
14 | DMZ Server. | Allow the internal Master Stack server to use domain credentials to access the DMZ Server's Background Channel. Only do this step if the DMZ Server is domain joined and there is two-way trust between your internal domain and your DMZ domain, otherwise do all the steps highlighted below to use certificates instead of domain credentials. On the DMZ Server, configure AllowedUsers on the Background Channel web application.
|
15 | DMZ Server Only when not domain-joined, or is untrusted. Skip this step if domain-joined and trusted. | Allow the internal Master Stack server to use certificates to access the DMZ Server's Background Channel. You will use the thumbprint from step 4. On the DMZ Server, configure AllowedUsers on the Background Channel web application.
|
16 | DMZ Server Only when not domain-joined, or is untrusted. Skip this step if domain-joined and trusted. | Enable Require client authentication on the Background Channel web application. This step changes SSL Settings for the parent, and the next step will change the same setting for specific child directories.
|
17 | DMZ Server Only when not domain-joined, or is untrusted. Skip this step if domain-joined and trusted. | For the Background Channel web application, enable Ignore client authentication on virtual directories: Content, Installers, PolicyDocuments and Updates.
Do not change any settings for the bin directory. |
18 | DMZ Server Only when not domain-joined, or is untrusted. Skip this step if domain-joined and trusted. | Increase the uploadReadAheadSize setting for the Background Channel. On a DMZ Server that is not domain-joined, Background Channel requires this to support certificate authentication, which is not required for a domain-joined server which uses Windows Integrated Authentication.
|
19 | DMZ Server Only when not domain-joined, or is untrusted. Skip this step if domain-joined and trusted. | Create a Policy virtual directory for the Background Channel.
|
20 | DMZ Server. | Perform an IIS Reset on the DMZ Server. |
21 | DMZ Server. | Modify the Switch host configuration file on the Tachyon DMZ Server to use the HTTPS binding set up in step 3. On the Tachyon DMZ Server, in the Tachyon installation directory Switch folder, modify the Tachyon.Switch.Host.exe.config file:
|
22 | DMZ Server. | Restart the 1E Tachyon Switch Host service on the DMZ Server, and then ensure all DMZ Switches are running. Review the Switch.Host.log files. |
23 | Internal Tachyon Server (Response Stack) and DMZ Server. | Copy existing Background Channel content from the internal Tachyon Server to the Tachyon DMZ Server:
Only the initial copy of content is required. From this point on, the Consumer API will maintain the content of the Background Channel on the Tachyon DMZ Server. PolicyDocuments can be omitted. When you click on the Deploy button in Guaranteed State (in step 27), then all policies will be regenerated and automatically copied to all registered Background Channels (see step 7 for registration of DMZ Server). If any source directory is empty then it means you have not tested that feature when verifying the internal Tachyon system in Step 1. This is not critical at this stage, but you should re-check later. |
24 | Internal Tachyon Portal, Tachyon Server (Response Stack) and DMZ Server. | Verify that the internal Tachyon Server can upload content to the Background Channel on the Tachyon DMZ Server:
|
25 | DMZ Server and external Tachyon client(s). | Verify an external Tachyon client can connect to the Tachyon DMZ Server Switch. Change the Tachyon client configuration (1E Client configuration file) to point at both the internal Tachyon Server and the Tachyon DMZ Server. This assumes you want Tachyon client devices to be able to switch between internal and external access. If you prefer, you can simply enter details only for the Tachyon DMZ Server.
|
26 | Internal Tachyon Portal and external Tachyon client(s). | Run verification steps to verify an external Tachyon client can download content from the Tachyon DMZ Server Background Channel.
|
27 | Internal Tachyon Portal and external Tachyon client(s). | Verify the external client can receive Policy updates.
You do not need any policies defined in Guaranteed State for this step to take effect. Pressing Deploy will create an empty policy. This step is required if you are making use of Guaranteed State |