Ubiquity Server Manual

Transcription

1 Ubiquity Server Manual Compatible with version 9.0 Introduction Ubiquity is the ASEM software solution for remote access and remote assistance on Industrial PCs and operator panels based on Windows operating systems, and their Ethernet and Serial sub networks. Page 1 / 21

2 Table of Contents Requirements... 4 SSL cipher suite configuration... 4 Ubiquity Server components... 5 Access Server... 5 Relay Server... 5 Configuration service... 5 Possible network topologies and network requirements... 5 Installation type and components... 6 Configuration setup... 7 Access Server configuration... 8 Access Server Configuration User interface... 8 DB connection string... 9 Initial database setup Server bind IP address Server public address Relay server public IP list Relay license count SSL certificate fingerprint Access Server license serial number Relay Server configuration Server bind IP address SSL certificate fingerprint SSL Certificates Using a certificate validated by a certification authority Generating a self-signed certificate Initial setup Generating the root certification authority Generating the certificate for a server Install SSL Certificate - Setting up the servers Security considerations Deleting a certificate Client configuration Runtime Page 2 / 21

3 Automatic Runtime late configuration Manual configuration Custom Runtime setup Control Center Manual configuration Custom Control Center setup Compatibility concerns Private Server not supported features Page 3 / 21

4 Requirements - Minimum operating systems: Windows 7 x64 Windows Server 2008 R2 x64 SSL/TLS Protocols Control Center and Runtime version 8 or later require TLS 1.2 to be enabled. Control Center and Runtime equal or minor than version 7 require TLS 1.0 and TLS 1.1 enabled. TLS 1.1 & TLS 1.2 are enabled by default on post Windows 8.1 releases. Prior to that they were disabled by default. So the administrators have to enable the settings manually via the registry. Refer this article on how to enable these protocols via registry: -.NET framework Client The Server application Setup, checks automatically for.net framework Client presence. In case the framework is missing the setup will abort. - Minimum database: SQL Server 2012 or later (Express edition or greater) - SSL certificate (self-signed or purchased) - Control Center Control Center version 5.1 or later is the client software installed on the supervisor computer (computer from which remote assistance is carried out). It allows the management of the domain resources and registered devices, allows to connect to a specific device, to instantiate a VPN, to manage remote serial ports, and to use interactive tools as remote desktop, file exchange, etc. - Runtime Ubiquity Runtime version 2.0 or later is a software service that runs on remote devices to allow remote access to the device itself. The service runs in background and can be controlled by the Ubiquity Runtime user interface or by the HMI application by means of command line directives. Ubiquity Runtime is available for ARM and X86 architectures, both on Win 32/64 and WinCE environments. SSL cipher suite configuration Ubiquity Runtime CE clients and Ubiquity Router version or older are not compatible with certain newer elliptic curve cipher suits. If you want to guarantee compatibility with such older devices, you can reconfigure your server to not use those elliptic curve cipher suits, but still use all other strong suites. This is harmless and can be easily performed by using the Local Group Policy Editor. To do this, follow these steps: - At a command prompt, type gpedit.msc, and then click OK. This starts the Local Group Policy Editor. Page 4 / 21

5 - Expand Computer Configuration, expand Administrative Templates, expand Network, and then click SSL Configuration Settings. - In the Setting pane, right-click SSL Cipher Suite Order, and then click Edit. - In the Help pane, scroll to the bottom of the pane to locate the "How to modify this setting" instructions. To modify the cipher suites, follow these instructions. - One possible configuration is the following: TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_2 56_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WIT H_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_12 8_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH _MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_N ULL_SHA Ubiquity Server components Access Server The Access Server is an application server that uses a SQL Server database in order to host all Ubiquity domain information (users, groups, policies, machine configurations, logs, statistics, etc.) and securely authenticate Ubiquity clients (Control Center and Ubiquity Runtime). It is also used as the initial rendezvous for Control Center and Runtime to initiate a remote access session. Afterwards, the actual connection is not supported by the Access Server but by one of the available Relay Servers. For this reason, the Access Server is data critical, but not latency or bandwidth critical. The actual database can be hosted in any SQL Server installation version 2012 or later, Express edition or greater. The database setup is not provided as part of the Ubiquity Server installation but the Express Edition can be downloaded for free from Microsoft. Relay Server A Relay Server is an application server that supports communication between Control Center and Runtime clients. It does not contain any information related to Control Center, Runtime or the Domain. However, it is important that its outgoing and ingoing bandwidth can satisfy the typical usage scenarios. The Relay Server is not data critical (actually, the data between Control Center and Runtime is encrypted end-to-end, so not even the Relay Server could decode the messages it is dispatching), but it is usually bandwidth and latency critical, in that it should not affect the end-to-end connection negatively as a bottleneck. Configuration service This service is installed automatically in the same machine that hosts the Access Server and/or the Relay Server. It is designed so that the configuration can either be done locally or remotely from the internal LAN by using an authenticated Windows user enabled for Ubiquity Server configuration. Possible network topologies and network requirements The Ubiquity Server infrastructure is composed by one or more deployments. A deployment includes the Ubiquity Server Configuration service and one Access Server and/or one Relay Server. Page 5 / 21

6 The whole infrastructure uses one Access Server only and one or more Relay Servers. In the simplest configuration the Access Server and one Relay Server are installed in the same machine. The machine must have two IP addresses because both servers need to listen for connections from the following ports (TCP only for Access Server and both TCP and UDP for Relay Server): Port 8888 was used instead of port 5935 in Control Center and Runtime versions prior to version 4. You should also open port 8888 if you want to provide compatibility with those client versions. Adequate routing rules should be configured to map public IPs to the private IPs of the Access Server and/or the Relay Servers, unless they are directly exposed to the Internet and thus the machine hold the actual public IP. In more complex scenarios the Relay Server can be installed in a separated machine from the Access Server, or multiple Relay Servers can be installed in separated networks to provide better geographical coverage and thus better latency. The Access Server should know all the public IP addresses used by the Relay Servers. Even if you are using a single Relay Server installed with the Access Server, you must configure the Relay Server public IP address in the Access Server. Relay Servers don t need a public domain name (because the Relay Server public IPs are given dynamically from the Access Server to the clients automatically), though the Access Server needs a domain name and clients should be configured to connect to that domain name. This can be done in several ways as described in the Client configuration chapter. Installation type and components The installation package includes both Access Server and Relay Server components. Depending on the desired overall server topology you can choose to install in a single machine: Page 6 / 21

7 In all cases the Server Configuration Service will be installed and will let configure Access Server and/or Relay Server through the included Configuration Client utility. Configuration setup The Access Server components (Access and Relay Server) can be configured by using the Ubiquity Server Configurator utility. This utility is a client application that connects to the actual Ubiquity Server Configuration service that is installed automatically by the setup. The utility can be used locally or remotely. If it needs to be used remotely, you can simply distribute the executable where it is needed. The configuration services authenticates using Windows users (either local users of the server machine or Active Directory users). Page 7 / 21

8 Also, authenticated users should be profiled so that they are allowed to modify the Ubiquity Server configuration. The list of the allowed users is an XML file stored in C:\Program Files\ASEM\Ubiquity\Server\ServerConfiguratorService\ServerConfiguratorServiceConfiguration.xml The file contains initially the following information: <?xml version='1.0' encoding='utf-8'?> <ServerConfiguratorService> <Users> <User>user1</User> </Users> </ServerConfiguratorService> user1, as in the example, is automatically added by the setup and contains the user that performed the installation. That is, that user is automatically enabled to further Ubiquity Server configurations. You can remove the initial user or add more users by configuring the file directly and by restarting the Ubiquity Server Configurator Windows service. The ServerConfiguratorServiceConfiguration.xml file should be protected by the standard Windows folder security policies, i.e. it should be changed only by a local machine administrator or by an Enterprise/Domain Active Directory user. Access Server configuration Access Server Configuration User interface The figure below shows the Access Server Configuration User Interface. Page 8 / 21

9 DB connection string The connection string is used to connect to the SQL server instance that will host the Ubiquity domains data. This connection string should be in one of the format accepted by.net applications for SQL Server. A trivial example with Standard Security is: Server=MyServer1;Database=Ubiquity;User ID=user1;Password=password1 Page 9 / 21

10 You can find more examples here: SQL Server Connection Strings for ASP.NET Web Applications Initial database setup The configuration service can setup an initial database with all necessary tables and stored procedures, provided the database already exists, the database is empty, the connection string is correct and a database user with the read/write and owner permissions is configured. You can initialize the database by pressing the Initialize button. Alternatively, you can import a non-empty database that contains the exported data from the ASEM Ubiquity Server public domain that is being migrated to the private infrastructure. In this case, you should take care of importing the given database backup in your infrastructure and simply enter the correct connection string without initializing it. Server bind IP address This is the local machine IP used by the Access Server to listen from incoming connections. It is typically NOT the public IP external clients will use to connect to Access Server, unless the Access Server is directly exposed to the Internet and the server has a local public IP address to use directly. Server public address External clients will use this address to connect to the Ubiquity private infrastructure. It should be a name, not an IP address, because it is more future proof and will not require already deployed clients to be reconfigured later. That said, it is still possible to use a static public IP, though it is discouraged. Page 10 / 21

11 Relay server public IP list You can add one or more public IPs for relay servers. The clients will automatically find the best relay to use dynamically case by case. To add a new relay server, insert the name in the field and press the button Add. Relay license count It displays the maximum number of licenses for Relay Servers. One Access Server installation permits one starting Relay Server. Additional Relay Server installations require additional licenses. You can add more licenses by pressing Add and entering the license serial number. SSL certificate fingerprint The fingerprint identifies the SSL certificate the Access Server should use among the ones installed in the machine. Please refer to the SSL Certificates chapter for details on how to obtain the required certificates. Once you have installed the required certificates in the machine hosting the Access Server, you have to type in this field the fingerprint of the Access Server certificate. You can find it in the certificate s properties, in the Thumbprint field, under Details tab. Page 11 / 21

12 Access Server license serial number License for the Access Server installation. This license depends from the Server public address field, so choose carefully and provide this information to the Customer Service for the actual License to be generated. Apply any changes by pressing Apply. You can also Start/Stop/Restart the Access Server service by using the buttons at the bottom of the window. Relay Server configuration Server bind IP address This is the local machine IP used by the Relay Server to listen from incoming connections. It is typically NOT the public IP external clients will use to connect to Relay Server, unless the Relay Server is directly exposed to the Internet and the server has a local public IP address to use directly. Page 12 / 21

13 SSL certificate fingerprint The fingerprint identifies the SSL certificate the Relay Server should use among the ones installed in the system that hosts the Relay Server. Apply any changes by pressing Apply. You can also Start/Stop/Restart the Relay Server service by using the buttons in the bottom of the window. SSL Certificates Connections between a client (Control Center or Runtime) and the Access Server are encrypted by using SSL protocol. To guarantee the protection, an SSL certificate for the host that will provide access to the server is needed. For example, if the server is running under host name accessserver.mycompany.com, a valid SSL certificate for that host name have to be provided (for example accessserver.mycompany.com or *.mycompany.com). You can get your certificate in two ways: you can buy it from a certification authority for your domain, or you can generate it by yourself. If you directly use IP addresses and not domain names for your servers, you need to generate certificates matching that exact IP addresses. If you move the server into another IP address, you must change also its certificate. However, the recommended option is to use domain names and certificates for them. Using a certificate validated by a certification authority If you bought a certificate for your domain name from a valid certification authority (such as VeriSign, GlobalSign or similar), you only have to install the certificate on the server machines by following the instructions provided by the certification authority. Then, update the Access Server and Relay Servers settings to use that certificate (see Access/Relay Server configuration chapter). If your certificate has been generated for some domain (e.g. *.mycompany.com), Access Server and Relay Servers have to use host names that match that domain (e.g. accessserver.mycompany.com). So, the certificate Issued To field must match the server host name, otherwise the certificate will be flagged as invalid by clients. Once everything is correctly setup in the server, no changes have to be made to your clients; they will work out of the box. Generating a self-signed certificate If you do not have a valid SSL certificate generated from a third party authority, you can generate a selfsigned certificate. This procedure will guide you through the creation of a root certificate and one certificate per host. The public part of the root certificate needs to be distributed to all the clients (Control Center and Runtime). For every server (one Access Server and one or more Relay Servers) a private key needs to be generated and stored in the certificate manager of Windows in that machine. Initial setup Inside the SSL sub-directory of the server installation directory you will find a Config.bat file that contains basic settings about the certificate generation. You can edit it and provide your company details to avoid typing them every time a new certificate needs to be generated. The following table explains the customizable fields in that file: Field name KEY_COUNTRY KEY_PROVINCE KEY_CITY Explanation Country name (two letter code) State or province name (full name or abbreviation) Locality name (e.g. a city) Page 13 / 21

14 KEY_ORG KEY_ KEY_OU Organization name (e.g. the company name) address Optional organizational unit name (e.g. a section) Generating the root certification authority The root certificate is the root in the certification path that guarantees the identity of your servers. It is important for you to grant the integrity and the safety of the private key. Access to the private key of the root certificate allows generating arbitrary certificates that your clients will trust. Go to the SSL sub-directory inside the server installation directory. Run MakeRootCA.bat. A message will notify you that every previously created certificate will be deleted. Note that, when you generate a new root certificate, you will lose the previous one, so be careful: do not proceed if you do not want to throw away your previous certificates. Type y and press Enter to proceed. You will be asked for some information to be used for the root certificate. If you edited the Config.bat file with your information, you can press Enter for most of the fields, as they will already have the right values. When you hit some field with changeme default value, you have to type a value for it: In Common name type a name for the root certificate (e.g. My Company Root CA); In Name type the name of the certificate (e.g. again My Company Root CA). The exact values you use are not important for a security point of view, however using meaningful names helps to visually checks the certificate generated. Once the procedure is completed, inside the sub-directory certs you will find the public certificate (in certs\public\ca.crt), and the private key (in certs\private\ca.key). Generating the certificate for a server Once your root certification authority has been setup, you can generate the actual certificates you need for your servers. There are few options, depending on what will be your server configuration: If you have a domain name (e.g. mycompany.com) and you want to use subdomains for Access Server and Relay Servers (e.g. accessserver.mycompany.com, relayserver1.mycompany.com, relayserver2.mycompany.com, etc.), you can generate one wildcard certificate (in this case *.mycompany.com) and use this one for all the servers. This is the recommended option. You can also generate one specific certificate per host name, instead of one wildcard certificate. Every certificate common name must match the specific host name in which it will be used. For example, you can generate the certificate accessserver.mycompany.com for the Access Server. If you do not have domain names for your servers, you can directly use IP addresses. In this case a wildcard certificate cannot be used. You must generate a certificate for each IP address. Every time a server needs to be moved to another IP address you need to generate another certificate for that IP address. This option is not recommended. Go to the SSL sub-directory inside the server installation directory and run MakeServerCert.bat. You will be prompt for a name for the certificate. This will be used for the file names related to this certificate, so do not use special characters (like *?\, etc.). Enter a meaningful name such as AccessServer or My Company. Then you will be asked for some information to be used for the certificate. If you edited the Config.bat file with your company details, you can press Enter for most of the fields, as they already have the right values. However, fields having changeme as default value must be changed as follows: Page 14 / 21

15 In Common Name type the host name of the server (such as accessserver.mycompany.com), or a wildcard certificate (such as *.mycompany.com), or the IP address of the server (such as ), depending on the configuration you want for your servers; In Name type a meaningful name of the certificate (such as Access Server or My Company Servers); After that, some extra attributes (like a company name) will be asked you. These are optional and are not visible in the final certificate. In the last step, enter an export password, or leave the field blank (although possible, this is not recommended). This password is then needed in the import of the server s private key. People having access to that file (and password) can use it to impersonate the server, so keep it in a safe place. The private key of the server will be saved in the subdirectory certs\private\<keyname>.pfx. The name of the key is the one entered at the beginning of the procedure. Install SSL Certificate - Setting up the servers After the certificates generation, you need to install the servers private keys in the machines in which they will run. This can be done by importing the key with the certificate manager of Windows by using mmc console, Certificates snap-in as shown in the following figures. Page 15 / 21

16 Note that you need to import the certificate for the machine and not only the current user. Select the folder Personal, right-click and select Import. Import the server key located in certs\private\<keyname>.pfx and enter the password specified as export password. Page 16 / 21

17 Make sure the certificate is valid and private key present Page 17 / 21

18 The root CA needs to be imported too, by adding it into the Trusted Root Certification Authorities for the machine. After that, check if the certificate is considered valid and contains the private key by opening it inside the Personal certificates. In case you need ASEM to support the automatic migration procedure of devices from the public server to your private one the public certificate (and not the private key) of your root certificate has to be sent to our technical support. You can find it in certs\public\customca.pem. Security considerations As previously stated, SSL certificates must be kept private for security reasons. Scripts for generating those certificates are by default installed with the servers; however, they can be moved in some other directory or machine if you prefer. Deleting a certificate If you create a wrong certificate, you cannot manually delete it from the certs subfolder. You have to use the RevokeServerCert.bat script. Upon execution it will print the list of certificates generated up to that moment and ask you the serial number of the certificate you want to revoke. Every line of the table corresponds to a certificate. You have to enter the value of the third column of the certificate you want to delete. For example, if the table shown is this: V Z 01 unknown /C=US/ST=CA/L=SanFrancisco/O=MyOrganization V Z 02 unknown /C=US/ST=CA/L=SanFrancisco/O=MyOrganization And you want to revoke the second certificate, simply type 02 as serial number. At the end of the procedure, that certificate will be deleted and it can be recreated by using the MakeServerCert.bat again. Page 18 / 21

19 Client configuration Control Center and Runtime clients should be configured accordingly to the Access Server address in order to connect to the private Ubiquity Server infrastructure. This can be done in several ways: Runtime Automatic Runtime late configuration Ubiquity Runtimes can be initially left configured to connect to the ASEM public infrastructure. A random ID+password will be assigned to them as usually upon connection. A Control Center connected to the private infrastructure can still try and register an anonymous Runtime by entering such ID+password. In fact Control Center will connect to the Public server as a fallback attempt in case the Runtime is not found in the Private server. The runtime will then migrate to the Private infrastructure. The Public server should know the Private server address and certification authority file needed to configure the Runtime. This information can be sent to ASEM technical support if you want to setup this kind of automatic configuration. Manual configuration In the general options two settings needs to be configured: - Options Server: change to Private. In Address enter the server address. - Click Import CA to eventually import the Certification Authority file. This is usually only needed if you are using a self-signed certificate. Custom Runtime setup The Runtime behavior can be customized by simply placing two files in the same directory as the Runtime setup: - CustomConfig.xml, should contain the following information: <?xml version='1.0' encoding='utf-8'?> <Config> <Version>1.0</Version> Page 19 / 21

20 <Params> <Param Name="ServerAddress" Value="your_server_address" /> </Params> </Config> - Optionally, copy the CustomCA.pem generated by the SSL scripts. You can also add the parameter IgnoreSSLErorr to CustomConfig.xml if you want the Runtime to close the connection to the Access Server in case of SSL errors: <Param Name="IgnoreSSLError" Value="0" /> This allows stronger security of your runtimes, because there is no way an attacker can impersonate one of your servers without actually having access to your SSL private keys. However, be careful, because if there are misconfigurations in your Access Server or Runtime, the Runtime will refuse to connect to the server even if there are no attackers in between. So, enable this option only when you are sure the Private server infrastructure is correctly configured. When run, if the setup finds CustomConfig.xml or CustomCA.pem, it configures the runtime to use your custom settings. This is supported in setup for Runtime version 5.1 or greater. Control Center Manual configuration In the general options two settings needs to be configured: - Settings Network Server: change to Private. In Address enter the server address. - Click Import CA to eventually import the Certification Authority file. This is usually only needed if you are using a self-signed certificate. Custom Control Center setup The standard Control Center setup can be customized to automatically install the proper server address configuration and custom Certification Authority file: - Unzip the Control Center setup package. - Modify the file LocalAppData\ASEM\Ubiquity\Control Center\CustomConfig.xml : <?xml version='1.0' encoding='utf-8'?> <Config> <Version>1.0</Version> Page 20 / 21

21 <Params> <Param Name="ServerAddress" Value="" /> </Params> </Config> - Copy the CustomCA.pem generated by the SSL scripts into LocalAppData\ASEM\Ubiquity\Control Center\CustomCA.pem. Compatibility concerns A certain Ubiquity Server installation is compatible with a minimum and a maximum version of Control Center and Runtime clients. The following considerations apply: - Old Runtime versions are always supported by the Server infrastructure. In fact, at the moment of writing the public server infrastructure supports Runtime 1.0 and later, however: o The private server infrastructure only supports version 2.0 and later. In case this is a problem for migrating your domain to a private setup, please contact Technical Support for more information. o Ubiquity Routers older than 5.1 cannot be configured directly by Control Center for the Private Server address. However, older Routers already deployed to the Public Server will be automatically migrated in case an existing domain will be switched to a Private Server. If you need to configure brand new Routers, make sure they are updated to the 5.1 version or later. - Old Control Center versions become deprecated over time. This is because Control Center is easy to update and let the server have less compatibility code. - Ubiquity Server should not necessarily be upgraded when newer clients are released. An upgrade is only required if new clients actually use a newer or extended server protocol. The release notes will clearly inform what is the minimum required Server version. Private Server not supported features The chapter contains the list of features available on the Public Server but not supported by the Private Server. License move to different hardware (Portable license type) Notification of new version availability and managed updating of platform components Device geolocation in a map view Page 21 / 21