In the program: • Overview of changes in the new version: security improvements, UI improvements. • Demonstration of a solution application scenario in case of needing to build disaster-resistant solutions (data center reservation). • Demonstration of integration with third-party network traffic balancing systems. Integration with xPointNetwork products.
Speakers: Alexander Kalinin and Pavel Mametyev, technical experts at OCS.
Today's topic is related to the recently released product — Termit version 2.3. Alexander Kalinin began talking about the innovations and improvements that appeared in this version, and about the vendor's immediate plans for the development of this area.
Improvements and innovations in version 2.3 were divided into several categories, but the broadest category is in terms of security. This is multi-factor authentication.
Terminal access for external users to improve security required multi-factor authentication. The ability to integrate Termit settings to use a third-party server on which you can implement a second factor or even several factors has appeared. The ability to connect several LDAP directories within a single installation has appeared. In our scenario, this is very important because we are considering options for complex projects in which there is a smooth transition from one LDAP directory system to another. That is, in this case, you can separate the process, and at some point be in an intermediate state, using both one directory and another. A very important innovation is Kerberos support for clients. That is, currently in version 2.3, you can already use this authentication method. This is very convenient for users. They do not need to enter additional credentials when starting the Termit client.
There is the possibility of authenticating an available client by certificate. The ability to redirect smart cards to a terminal session has appeared, which also increases the scope of this solution.
Changes in the management part.
The role model is expanding, a new role has appeared. It is called an information security auditor. Users for whom this role is assigned have the ability to obtain information about the infrastructure, access to logs, but without the ability to make changes. Improvements have appeared in the category of applications and desktops, that is, grouping. Here the vendor began to move in a direction similar to the direction of movement of the departed foreign leaders. There was also the allocation of applications and categories. Now you can assign an application by category to a group of users at once. A separation of the list of applications and desktops has appeared. And a small but visually very important function, you can now upload icons for published applications and desktops. The interface becomes more pleasant and user-friendly for users.
Changes that affected the client application. A proprietary X2Go client for macOS has been developed. It has the necessary authentication functionality related to security changes and supports SSO.
Authentication via Kerberos protocol. The vendor is also moving towards developing the entire stack of elements, in particular, a proprietary RDP client for Windows has been written. An important point, support for DPI settings has been added on the client side. The only thing is that at the moment, this is all configured on clients and within policies - this has not yet been implemented. The clipboard has been improved, it is bidirectional and allows you to exchange data via the buffer with Windows, Linux, macOS clients, a Linux terminal server and back.
Regarding the support of operating systems on which Termit components are deployed.
The vendor continues to follow its partners and leaders in the domestic market. For this reason, it became possible to deploy components on new versions of the Astra 1.8 and RED OS 8.0 operating systems. And it also remains possible to deploy on OpenSST, on global and domestic operating systems, Alt Linux is also supported. In particular, our demo laboratory is deployed on Alt Linux. Support for these OSs has been added to almost all system modules, brokers, balancers, terminal servers, gateways, and desktop operating systems.
Now let's move on to the vendor's immediate plans.
This year, the vendor has planned two releases: release 2.4, which will be released in August of this year, and release 2.5, which is scheduled for release at the end of this year or at the beginning of next year. It all depends on how quickly the claimed functionality will be implemented.
Vendor Orion soft is starting to move towards implementing VDI in its product. What follows from this? Support for new protocols will appear, in particular, the fairly widespread Loudplay protocol for weak channels, for channels requiring optimization. Since VDI is the process of automatically deploying virtual personal machines, there will be natural integration with the virtualization platform to automate this process. zVirt will be used as the virtualization platform for Termit. That is, third-party virtualization platforms will not be able to be used as a platform for Termit. It will be possible to create terminal server templates, virtual machines, and groups of virtual machines. There will be an option for both full clones and linked clones, linked clones. All virtual machines will be implemented with both static connection to the session and with dynamic connection. Roaming profiles will be implemented in order not to be tied to specific virtual machines and the ability to update them. And a virtual machine lifecycle will be implemented, which will allow updating virtual machine pools without reinstalling systems.
As for version 2.5. This version includes the implementation of automatic deployment of the Termit infrastructure on zVirt, integration with SDN from zVirt, which will also optimize the process of dynamically deploying virtual machine pools. Policies for device passthrough will appear. In this part, policies will already be implemented with which you can manage the parameters of the user session from the server side. And the implementation of a web client is announced. Also, along with this release, new editions of the Termit VDI and zVirt VDI products will appear. That is, you will be able to purchase the same zVirt at a certain price, for a specific task. This way you will have a chance to optimize costs.
Now let's talk about the scenario that we implemented on our stand. The scenario is as follows. It is assumed that there are two sites, they are not connected to each other. The elements of each site were located on one of the sites. Users could connect to either one site or the other.
In this case, we implemented the following scheme: there are two installations, site 0 and site 1. Each site has a fault-tolerant balancer cluster. The balancer is called xPoint UppScaler. This is a product from xPointNetwork, a Chinese vendor that has been on the market for quite some time, since 2018. It prepares corporate-class balancing solutions that allow you to implement fault tolerance of the entire system. It is possible to organize balancing of all your services within a single system. You will not need to introduce several balancers for each system. It is possible to configure the state of the balanced services in a complex way. And one of the most important points, in particular for this task, is support for global balancing, which will allow you to combine geographically distributed services. In this case, there is a balancing cluster, a fault-tolerant pair on one site on site 0 and a second pair of balancers on another site, site 1.
These balancers are combined into a single GSLB configuration. That is, they participate in the name resolution process. When requesting a resource, in particular, here Termit, vlab, OCS.ru, the client will resolve the name, and it will be returned either one address or another, located either on one site or on another site. In the case when all systems are working normally, balancing will occur between different sites, while the client will be authorized either on one site or on another site, which is less loaded at the moment. In the event of a failure of one of the Termit brokers, for example, on the site on site 0, the client with the name Termit, vlab, OCS.ru will also be resolved to two virtual IP addresses. Client traffic will already be redistributed differently. One of the brokers will be excluded from balancing.
And the third option shows a disaster scenario when one of the sites completely fails. In this case, all nodes from one site will be unavailable and the name Termit, vlab, OCS.ru will be resolved to only one IP address, fixed for the working site. And even if in this case one of your brokers is also unavailable, the services will be in a non-working state, then the client will still receive a response, he will be able to authorize, the terminal servers will be able to register on the broker and the client will be able to access his session.
Now I will demonstrate how this is configured on the balancing side.
We have two clusters. The first cluster is located on the main site, site 0. It consists of two nodes, two balancers. There is also a second cluster. There is also a fault-tolerant pair there.
Virtual servers are configured on each of the clusters. Here we have configured in accordance with the vendor's recommendations. In principle, this instruction is sufficient to perform the configuration on this balancer. There is a virtual balancing server for client connections, there is a virtual server for connecting terminal servers, for registering on brokers and, for example, redirecting from an unsecure port from 80 to 443. It is also implemented on the balancer side. It allows this traffic not to be transmitted to brokers, but the redirect occurs at the stage of connecting to the balancer. It is also visible here that you can determine the state of the balanced services. In particular, at the moment, a test port is configured, which is used to determine the state of the broker's operability. Also, during operation, in the event of performing some necessary manipulations with brokers, you can turn them off from here. For example, transfer one of the brokers to maintenance. After performing this procedure, all client connections will be redirected to one of the brokers. Also, both of these sites are combined into a single GSLB configuration. That is, this is already a part related to global balancing, to the name resolution process. There is a common name. Here it is implemented how we created a separate zone related to GSLB, and the name that the client will use to connect. For this zone, the balancers act as an authoritative DNS server. The resolution process will return either one IP address or another. The state of this address will be determined by the test that is configured. Here, for example, just this IP address will be pinged. You can configure more complex checks: an open port, or a specific request.
How will this look from the client side? When connecting, if we refer to the common address Termit, vlab, OCS.ru, then in the end we get to the virtual IP address that belongs to site 1. If we exclude this site from global balancing, or it fails, we can simulate this by disabling the connected GSLB service in the virtual server. After following the same link, we already get to another site. That is, there will be no service failure. The client will connect to the site that is available at the moment.
In principle, this is probably the description of the implemented scenario. There are two unrelated sites in the graphical interface. Application categories have appeared, that is, you can create different categories, for example, Internet, office applications. For applications, it became possible to specify icons that will be displayed on the side in a more understandable form for users. As for global settings and OLDUB directories, that is, at the moment we have one OLDUB directory connected here, but it is possible to add another OLDUB directory, and within the existing one connected here you can configure Kerberos authentication. In this case, if it is configured, you will be able to authorize, authenticate in the client using a ticket received earlier during authentication in the operating system.
Illustrations provided by the press service of Orion Soft and OCS