Local thin client configuration is WRONG. Here is why
With the increase in the adoption of “digital workspace,” employees are no longer bound to a fixed location to carry out their work. It no longer matters whether they are at the office, at home, or in a cafeteria on a beach. Companies have adapted to this digital change by utilizing some great tools and products that are out there in the market.
One of the solutions that play a major role in this change is the device used by the user or the endpoint device. Companies are adding endpoint devices in their hardware fleet either in form of thin clients or repurposing their existing hardware as a thin client. This approach provides them a good, secure, and convenient way to manage the devices using a management tool. Even if the user is working remotely, the management tool can have the capability of handling the thin client configuration remotely.
Using a thin client guarantees that there are no security vulnerabilities on the user’s devices, which in return makes the enterprise data safe. Moreover, the configuration of these thin client devices is controlled by the IT department, making sure that there is nothing the user can do to make the device vulnerable to attacks. In a nutshell, there are many security benefits that thin client devices bring to the table.
In an ideal scenario, the thin clients are configured remotely using a management tool that comes as part of the complete endpoint solution. The desired configuration is set by the administrator and then it is pushed to the endpoint devices. The management tool is capable of handling thousands of devices at a given time. The management tool communicates to the devices using different protocols such as HTTPS, SSH, etc., depending upon the vendor implementation.
Having the possibility to change the thin client configuration locally is also an option that some vendors provide. However, that is something that completely defeats the purpose of having thin clients from a security as well as a support point of view.
Why it should not be allowed to change a thin client configuration locally?
We’ll have a look at a few of the reasons why a local thin client configuration change is a wrong way of doing things:
Local configuration actions can create security breaches
A thin client can be classified as a dumb computer as it is used only for connecting to the applications in the cloud or a data center. However, to connect to these services, it uses some tools internally. The accessibility and security parameters of these tools are configured by the administrator as per the requirement. But if the user can modify anything to facilitate his or her use, it can pose a security vulnerability.
Even if the user has no intention of misusing it, other third parties can take advantage of it and exploit the device.
Local configuration actions generate more work for support teams
One of the main reasons for adopting a thin client solution is to make the management of devices simpler. It reduces the amount of work the IT support team has to do to maintain and configure the devices. Providing a tool to change the thin client configuration locally defeats the purpose of the solution entirely. Each device can now have a different configuration which in turn increases the workload of the support team. They have to monitor each device to be sure that there is no security vulnerability due to the changed configuration.
If thousands of devices are deployed in the enterprise, the support person needs to go to each device to configure them via the local configuration tool. It is a very tedious task that can last up to days but can be achieved in hours if all of them can be configured remotely together.
Also, there are chances that the user may misconfigure something, or make a configuration change that may impact the functioning of some other applications. Due to this, it can create an enormous amount of work for the support team, and they may need to go to the user’s location to troubleshoot or reconfigure it. In a scenario where the users are working remotely, this is almost impossible to achieve.
In case you have no choice: Use password-based local configuration tool
While we strongly recommend not to have a local thin client configuration tool, there might be some edge cases where this is required, and there is no other alternative. In such scenarios, the best approach from a security point of view would be to have a tool that is password protected. It will add at least some layer of security, preventing unauthorized configuration changes on the devices.
Apart from this, the password should follow some rules such as:
- Should be unique per device
- Should be long and complex enough that it cannot be cracked that easily via some tools
- Should be changed regularly (e.g., every 1-month)
- Should not be reused anywhere else
To get more insight on what type of endpoint solution can work for you, schedule a FREE consultation with one of our experts. Even though we are a thin client vendor, we keep our consultation general and never push our devices unless requested.
- Why local authentication on thin client is a bad idea 17 January 2022
- Wishing you the best for 2022 3 January 2022
- ZeeOS now supports the latest Citrix client 2112 and latest VMware client 2111 14 December 2021
- Chip shortage crisis : transform this threat into an opportunity to upgrade your endpoints 30 November 2021
- How to make Zoom or Microsoft Teams work in your VDI infrastructure 17 November 2021