These release notes contain information relating to a new version of Netop Remote Control (Windows, Linux and Mac) including the ActiveX Guest (nguestx.ocx). Version 11 introduces extended management functionality of remote systems particularly where no desktop is available for traditional remote control. Further security and connectivity improvements have also been implemented including RADIUS support and WebConnect Sub-domains.
In order to use Netop Remote Control 11, you will require new license keys. Customers who have a valid Netop Advantage annual support and upgrade agreement are eligible to upgrade to the new version at no additional cost and should receive their upgrade license keys shortly after the public release date.
If you have questions about your license or wish to purchase an upgrade to Netop Remote Control 11, please contact Netop Customer Service or your local Netop Partner for more information.
In order to help our customers extend their cross-platform remote support capabilities across the enterprise, Netop has introduced further support for the Linux platforms.
Both Guest and Host modules are now officially supported on OpenSUSE 11.4 and 12.1 including 32-bit and 64-bit editions.
The Guest and Host installation files for OpenSUSE are available to download from our website as a
compressed (TAR.GZ) archive.
For further installation instructions, please refer to the Installation Guide for non-Windows platforms, which is available on Netop.com.
Introduction
RELEASE NOTES
Shipping date:Product/version/build: Remote Control 11.00 (2012027)
ActiveX Guest 11.00 (2012027) 30th January 2012
Platform
In order to extend the support and management capabilities within the Netop Remote Control solution, a new Tunnel function has been implemented. The Tunnel establishes a secure connection between the Guest and Host and allows application ports to be redirected from the Host to the Guest through the Tunnel. This allows the Guest to run local applications whilst interacting with the connected Host without having to remote control the Host machine.
The Tunnel is ideally suited, but not exclusive to environments where no traditional desktop is available for use with standard remote control (screen, keyboard and mouse control); however support and system administrative tasks still need to be carried out remotely whilst conforming to industry regulatory standards such as PCI-DSS, HIPAA and FIPS.
Such environments can include embedded Linux systems where operating machinery and hardware contains a streamlined version of a Linux operating system, for example, fuel dispensers and retail systems. In addition, enterprises can also take advantage of the Tunnel for managing and supporting their Linux Desktops and Servers using common applications and services such as Shell clients, HTTP and SFTP.
The Guest’s ability to use the Tunnel along with the associated ports can be governed by the central Netop Security Server solution. This allows organizations to apply granular access privileges. Even when remote systems have a desktop, it may not be required to give Guest users full remote control access on certain machines but limit their ability to use certain application ports through the Netop Tunnel.
Control tunnel and port access for different individual users and groups with the Security Server:
The Netop Guest can launch a Tunnel session from the toolbar or context menu in the Quick Connect, Phonebook or History tabs:
Once the Guest has been authenticated, the Tunnel console will appear confirming which remote ports are available and what randomly assigned local ports can be used by the Guest:
Third-party Shell access is still available when port 22 is redirected through the Tunnel. For example, the above connection also allows a local Shell client, i.e. Putty, to be used to administer the Host machine through the local port 52306:
The Tunnel console will continue to update with any processes or applications that are using ports through the active Tunnel session:
RADIUS support
The Netop Security Server has been extended to offer authentication against RADIUS (Remote Authentication Dial In User Service) environments.
RADIUS is a client/server protocol that is often used to centrally validate remote users and authorize their access to existing network resources integrating well with existing technologies including VPN, RAS, Active Directory and Token based authentication solutions. Using RADIUS with Netop Remote Control allows the Security Server to authenticate remote support sessions via compatible multi-factor authentication methods, where the Guest user needs to provide their username and password along with a one-time generated passcode that can be derived from a variety of sources including hardware devices or SMS tokens.
In order to use the RADIUS implementation the Security Server should be configured to use Directory Services authentication. This requires that the Preferred Guest type is set to ‘Guests enter Directory Services username and password’ in the Security Policies section of the Security Manager.
In addition, a connection to a RADIUS server should also be configured in the Security Manager and a new tab called ‘Radius Server’ has been added to the Directory Service settings for this purpose. Finally, in order for the Guest to enter their token passcode when authenticating, the ‘Request Token Passcode’ option should be enabled. This is available in a new Properties section under the Directory Services definitions in the Security Manager.
RADIUS options can be configured under Directory Services definitions in Security Manager:
Linux/Mac Hosts and Windows authentication
When using the Netop Security Server with Windows authentication, the Guest is now able to connect to a Host running on Linux or Mac.The Security Server offers enterprises the ability to manage remote control access from a central location. This enhancement extends the centralized security management options by allowing the existing Windows account to be used by the Guest users when authenticating against a Linux or Mac Host via the Security Server.
In order for this authentication to work effectively with the Security Server, the preferred Guest type should be set to Windows User and the Host type should be set to Netop Host ID. Once your Linux Host machines have been added to the Security Server database, they can then be included within any role assignment.
Future releases of the Security Server will also introduce the ability to use Workstations as the preferred Host type allowing existing non-Windows objects to be used directly from the Windows Domain. Define the correct Guest and Host type in Security Policies:
Setup role assignments using Netop Host IDs as Host objects:
Logging
There have been a number of enhancements to the way Netop Remote Control handles log data for auditing purposes. These improvements include:
The time stamp used for all Netop related events includes seconds. The resulting format is YYYY-MM-DD HH:MM:SS
The Security audit events now include ’Confirm access granted’. This is to show when the Confirm Access dialog has been accepted by the end user
The Security audit events also include ’Confirm access with password denied’. This is to show when the Confirm Access password dialog has been denied by the end user
The field used in the Security Server database has been extended to 254 characters to better handle custom Guest and Host name strings
Multiple sessions
Version 11 delivers some important changes to the core communication layer greatly improving the way Netop Remote Control handles multiple sessions removing previous connection limitations and dependencies. These improvements include:
Guests can have multiple support sessions running simultaneously when using a WebConnect service
Hosts can have simultaneous Guest connections when using a WebConnect service
Netop Gateway can handle multiple outbound TCP sessions to reach different Host machines
This now offers much improved usability and flexibility for busy support environments where multiple support sessions need to be running at the same time for increased productivity and collaborative purposes. In addition to using the version 11 Guest, you must also be using Connection Manager 1.9 (build 2011xxx or above) to take advantage of these improvement in a WebConnect environment. If you are using the hosted services provided by Netop, there are no further changes required.
Guest with simultaneous support sessions (file transfer and remote control) using WebConnect:
Kerberos authentication
In some Windows Active Directory environments, it is not possible to communicate between Netop applications using the traditional NTLM authentication methods when the Host is configured to use Windows Security Management as the preferred authentication type. This would be the case in an Active Directory environment where multiple Domains existed with the same NetBIOS name. For example,
Parent Domain Child Domain NetBIOS Name Domain1.local Sales.domain1.local Sales
Domain2.local Sales.domain2.local Sales
In this example, each child domain has a unique FQDN (Fully Qualified Domain Name) but uses the same NetBIOS Domain name.
In order for the Guest to connect to Hosts in such environments, the following should be added to the NETOP.INI file on the Guest machine:
[DANWARE]
ForceKerberosAuthentication=1
Restart the Guest application for the changes to take effect. When connecting to Hosts using this method, the FQDN of the Host should be used. The Guest should also supply the FQDN for the Domain name at the authentication stage. Kerberos authentication is not backwards compatible with older Hosts and cannot be used with Hosts that do not require Kerberos authentication.
Use the FQDN as the connection name:
When transferring the screen from a Host machine running Windows XP, the Guest would display an incomplete image when the screen transfer method was set to Command Mode The ’Disable file transfer before local logon’ feature did not take effect when configured with a Host running on Windows 7 or Windows Server 2008. This has now been resolved and requires an update to the Host application
Support case ref: 59694
If the Host application was bound to a network interface and the interface was not available at the time of the binding process, the Host would not load correctly. The issue was more evident when the Host was set to bind to a wireless adapter and would load before the adapter was initialized
In some situations the installation of the Host application would fail with a message saying ’Error adding or removing Host service’. The error was in fact caused by the Netop driver during installation and this behaviour has now been rectified
Support case ref: 57988
Upon connecting to a Host running on Windows XP with a remote control session, the transferred screen would be black. The problem would occur when attempting to connect using Command Mode and required a connection using Bitmap Mode in order to view the Host screen correctly. The problem was related to the Netop driver and has now been resolved
Support case ref: 59431
The Host application would incorrectly accept a license for a Security Server, Gateway or Connection Server during the installation process. Attempting to use a non-Host license key will now result in an error being displayed
When the Guest browsed for Hosts using a UDP communication profile, Hosts running on Linux or Mac operating systems were not displayed in the browse results
When accessing the Program Options on the Linux Host, the Host Manager window size was not set correctly. This has been resolved making it easier to view the available options without resizing the window
