Important Note: Whereas normally the first beta version after a new release will only have a few small changes, this beta release has a large number of features that have been under development in an alpha branch. Please review these changes carefully before deciding whether to move to this beta version of software and/or whether to use the new features provided. Pay careful attention to the discussions on certificate management should you choose to use the encryption methods described in this release. Also the security options represent optional settings. If you are uncomfortable with certificate management, you can leave these settings as they are after the update, and your system will continue to function as it has.
This version contains a complete update of the operating system including updates to the linux kernel, the system logging application, most of the underlying linux operating system packages, the web server, the shared web page application packages, and the framework under which the primary PathfinderCore PRO applications are compiled and executed. Please report any problems you might experience as this is a major update.
In previous versions of PathfinderCore PRO there was a separate web socket port for WebSocket communications between the webpages and SapV2 and the metering services. These are now all handled by the web server using port 80 (or port 443 if https is enabled).
You may encounter a cpu spike for the first couple of minutes on the first start after moving to this version. There is an encryption cypher that is used as a part of the TLS encryption that gets generated. This only occurs the first time you move to a version with these features. You should not enable https security options until this spike finishes. A future build may streamline this.
This version introduces a new navigation bar item called Security. This section allows a system administer to manage SSL/TLS certificates, whether services are enabled and exposed to the outside world, whether their communications should be encrypted, as well as alternate authentication methods.
For customers wishing to encrypt browser and other communication traffic, the security section of Pathfinder Core PRO makes this possible. However, this encryption is based on certificates and a good understanding of certificate based encryption and the corresponding trust relationships are critical to making this work correctly. Throughout the security discussions below we will be discussing several different types of security certificates which may or may not be needed depending on which encryption options you choose to enable. These different types of certificates include:
Self Signed Certificates: These are the default certificates created when enabling https. These present a public certificate to browsers attempting to connect to PathfinderCore PRO, and are used in the subsequent encryption of the traffic. However, since self signed certificates are not signed by a trusted authority, browsers will not by default trust the certificate and will therefore present a warning that you will have to click through in order to access the system's web pages. It is also possible to add a PathfinderCore PRO installation's self signed certificate to a browser's trust list, and that browser will from then on trust that PathfinderCore PRO installation.
Publicly signed certificates: Pathfinder allows you to generate a certificate signing request which can be taken to a publicly trusted certificate authority such as Let's Encrypt to get a trusted certificate. This solves the browser warning issue. However, you can usually only get a publicly signed certificate if you are using public IP addresses. Therefore, if your PathfinderCore PRO is not accessible via a public DNS/IP address, then this option will not be available.
Internally signed CA certificates: An option to the publicly signed certificate is to set up your own internal certificate authority. If you are in an Active Directory domain, you can add the certificate authority role to your Active Directory server. Then you can sign your certificates using the Microsoft CA and any computer in the network that trusts the Microsoft CA will also trust certificates signed by that CA. This allows you to use internal private IP addresses and DNS and still present certificates that the browsers in your network will trust.
Root Certificates: These are certificates that Pathfinder trusts as authorities or just as trusted certificates. While the certificates above are presented to browsers trying to access PathfinderCore PRO, root certificates are used when Pathfinder tries to access other systems using encrypted traffic. For example, if PathfinderCore PRO tries to authenticate with an LDAP server using encrypted traffic, Pathfinder needs to trust the certificate presented by the LDAP server before the communication can take place. Also if encryption is added for clustering communications, all servers in the cluster must trust each other's public certificates. In the case of publicly signed certificates, PathfinderCore PRO includes the Mozilla public authorities. In the case of internal CAs, you need to add the public root certificate of that CA to Pathfinder's root CA list to trust certificates that CA signs. And lastly it is possible to simply add a self-signed certificate to the trusted list.
Much more will be presented in the sections below as we cover various encryption methods, but a good understanding of encryption and certificates is necessary to correctly enable and use some of these features. It is also important to note that certificates have a time limit built in, and so must be renewed periodically. The length of time a certificate is valid for depends on the certificate provider and the type of the certificate, but one to three years is usually the maximum. You can create much longer times with a self-signed certificate or by managing the options in a private certificate authority.
The web server option allows you to switch between http and https. The https option will encrypt all traffic between the browser and PathfinderCore PRO. Enabling the https setting will forward any attempts to access the device using http to https instead.
https requires an ssl/tls certificate in order to function. By default there is an automatically generated self-signed certificate. Because self-signed certificates are not issued by a trusted authority, this means you will be presented with an insecure message from the browser.
Clicking on advanced and proceed link will let you get past the warning and allow access to the system while still using encryption for the data between the browser and PathfinderCore PRO. There are several alternatives for eliminating the browser warning. The first is to add the certificate as a trusted certificate to the browser on each system that needs to access that instance of PathfinderCore PRO. This may be simplified in an Active Directory domain by distributing it using a group policy. Alternatively, you can upload your own certificate into the system by clicking the manage certificates link.
Click on the Update link for the web server certificate.
This will display the current parameters of the certificate used for the web server. To generate a new one, click on the Request Cert button. This will present a view of the configuration file settings needed to generate a certificate request.
By default the settings will include the local IP addresses in the alt_names section. You will need to add any other DNS names or external IP addresses which will be used to access PathfinderCore PRO into the configuration. If you have been manipulating this data and wish to return it to a factory default setting, clicking the “Reset Csr Data To Default” to reset the data.
It is important to understand that most public certificate providers such as Let’s Encrypt only allow publicly verifiable IP addresses and DNS names.
Click the Request Cert button in order to generate a signing request file based on these settings and PathfinderCore PRO’s private key.
Note: This will directly modify the signing request data. Validation of correct data structure is limited at this point in time.
After the request is generated you will be returned to the Current Certificate screen, but now the view Request and Fill Request buttons will be available. Click the View request to see the certificate request data that has been generated.
Copy this data into your certificate authority’s tools for generating a signed certificate.
Important notes for Microsoft CAs: If you are using an internal Microsoft certificate authority, each signing request requires an additional field which is not standard to most other signing requests. Specifically it requires you to define a template. To do this copy the certificate request into notepad, save it as a file like webserver.req and then move it to the Microsoft Server. Accessing the Pathfinder Core PRO web pages directly from the CA server may require installing a compatible browser on the server or loosening the browser restrictions to allow the web socket traffic. Or you can save the data using a windows 10 machine and move the files to and from the certificate server. Then open a command prompt on the Microsoft CA and type:
certreq -attrib "CertificateTemplate:WebServer"
This will launch Microsoft’s certificate signer using the WebServer template. The signer will ask you to select the certificate signing request file. It will then ask you to select the certificate authority to use for the signing.
Finally, it will then sign the file and ask you to store the signed certificate to a new file. For example you could save it as test.cer.
Whether you sign your request with a Microsoft Certificate Authority or some other CA, the final step is to click on the FillRequest button in PathfinderCore PRO, and paste the contents of the new certificate into the Signed Certificate Data field:
Clicking apply will then go through a process of validating and storing the certificate, restarting the web server and then returning to the security web page.
It is important to understand that using certificates signed by an authority other than an official public authority will still display as invalid in browsers unless that authority has been trusted on the corresponding machines. For example, if you sign the certificate using a Microsoft CA, it is assumed that you are also pushing the Microsoft root CA as a trusted root certificate to the client computers on your network.
The update web server certificate dialog also includes a Regen Self Signed button.
Clicking this button will issue a warning and then will remove any custom web server https certificate and generate a new self-signed certificate. Note that this will also generate a new private key for this certificate.
This option defines whether the unencrypted SapV2 port 9600 is available externally or only within the box (internal). Since internally some inter-process communications use this, the port must be available internally. However, this option will prevent it from being accessed from outside the box.
This option will enable a version of the SapV2 port that is encrypted using TLS encryption. The port will use the same certificate that is used by the https web server encryption. We can provide a tool we have created for interacting with the encrypted version of SapV2 in a similar way to how putty interacts with the unencrypted version. Please review the section below on security and clustering for details on how this setting affects clustering communications.
This option allows the metering to be exposed externally or internally. If it is exposed internally only, it will still work for any web browser user interfaces built in PathfinderCore PRO that display metering. This is because those interfaces connect to the web server which then connects internally to this port. This only needs to be exposed externally if you are using a third party application with the metering service.
This option allow you to turn on and off the ssh port. Typically this port is only used for support to get into the underlying operating system when troubleshooting a problem. Disabling this except when support needs it will tighten the security of the system somewhat by removing the open port.
The device passwords option will retain the passwords used for logging in to devices, the email password, and the clustering password in symmetrically encrypted or unencrypted form in the server storage. It is important to understand that once the passwords have been encrypted, you cannot downgrade to an older version of the software that does not support this feature or restore a backup with the encrypted passwords to an older version of the software. If that is required you need to switch back to the decrypted form before downgrading. Changing this setting will kick off a function to encrypt and/or decrypt all instances of these passwords in the system.
This option requires an optional External Authentication license. Beta testers may request a 90 day evaluation license for this feature. Once that license is installed on the system, this option will be available. It allows you to switch between using PathfinderCore PRO’s internal user list to authenticate users, and using an LDAP server to authenticate users. For example, enabling LDAP in an Active Directory server will allow you to use the users in your active directory domain as the login credentials to access PathfinderCore PRO. This allows a single point of user management rather than having to manage users in your Active Directory domain and your PathfinderCore PRO system.
It is critically important to understand how this feature works before trying to enable it or you may lock yourself out of the system. If that happens see the recovering from an authentication lockout section below.
After enabling LDAP, each login will send the username and password credentials to the LDAP server for authentication. If authentication is successful, Pathfinder will also request a list of the groups that the user is a member of. One of those groups must match a user security profile in PathfinderCore PRO for access to the system.
You can create a security profile in PathfinderCore PRO by adding a user with the name you will use for the group name in the LDAP server to Pathfinder. Then you configure that group's permissions in PathfinderCore PRO. While creating the user in Pathfinder you will have to add a password, but the password will not be used when in LDAP mode. For example, if your LDAP group name is PcpAdmin, then you need to create a PathfinderCore PRO user with the name PcpAdmin and configure the correct permissions for it. Then within Active Directory you can add users to the PcpAdmin group and when those users use their Active Directory user name and password to login to PathfinderCore PRO, they will have the rights of the PcpAdmin security user profile because they are a member of that group in Active Directory.
A user can pass correct credentials to LDAP, but not be a member of any group that is allowed to use PathfinderCore PRO and therefore be denied access. Therefore there are number of steps that should be taken before enabling LDAP authentication.
Make sure that the url you will use for the LDAP server is resolvable by the DNS servers specified in PathfinderCore PRO. Usually for Active Directory, this means adding the Active Directory servers as DNS servers in the PathfinderCore PRO DNS section.
Make sure you have created a group in the LDAP server that matches an Administrative user in PathfinderCore PRO.
For example, create a PcpAdmin user in PathfinderCore PRO that has Admin privileges and create a PcpAdmin group in an LDAP enabled Active Directory server. Warning: this is a case sensitive match.
Make sure you have at least one user in the LDAP server assigned to the administrative group.
If you are using Active Directory, make sure that LDAP is enabled on your Active Directory servers.
If you wish the LDAP communications to be encrypted, you need to have a public certificate in the LDAP server or have an internal certificate authority and import the correct root certificate into PathfinderCore PRO so that PathfinderCore PRO will trust the internal CA's certificate. See more below on this.
If these steps are not taken it is likely that switching to LDAP will cause you to get locked out of the system.
To configure LDAP, use the Authentication drop down to display the LDAP configuration settings.
Enter the proper parameters for your LDAP server.
X-Ldap-URL: comma delineated list of LDAP servers to try for authentication.
X-Ldap_BaseDN: The point in the domain structure that will be used to search for users.
X-Ldap-BindDN: The LDAP user that will be used to query the domain. It is highly recommended that this user have read only rights to the domain. It is the user that PathfinderCore PRO will use to access LDAP and authenticate other user credentials.
X-Ldap-BindPass: The password for the BindDN user.
X-Ldap-Starttls: Whether the LDAP communications should use TLS encryption which must be enabled on the LDAP server and have a proper certificate trust relationship configured.
The test button can be used to test your configuration options before applying them. Make sure you test before applying, as applying incorrect parameters can result in a lockout from the system. Generally we recommend getting LDAP working correctly without TLS encryption first, and then working through the TLS option. Clicking test will ask for a username and password which will then be passed to the LDAP authentication engine along with the entered parameters. A successful test means that the system was able to contact the LDAP server and use the bind paths and user to authenticate the user credentials supplied. It does not test for proper group membership. So a successful test can still result in a lockout if the authenticated user is not a member of a group that has a matching user profile in PathfinderCore PRO.
Once the test is working and you are sure that the users are a member of groups with matching security settings in the users section of PathfinderCore PRO, you can apply the changes. This will cause the system to present a new login screen which should then rely on LDAP user credentials for access to the system.
A comma delineated list may be used in the X-Ldap-URL section in order to try multiple LDAP servers. It is important to understand that the system will loop through the LDAP servers in order and attempt to bind to each one. If a bind is successful it will then try to authenticate a user. If the authentication fails, the system will not try the next server. The looping mechanism is only to achieve a successful bind. It is assumed that these are synchronized servers as far as the user data is concerned so a failed authentication on an active LDAP server equates to a failed authentication on all active LDAP servers. It is also important that each additional LDAP server connection that is tried adds delay to the authentication process. So it is preferable to make your most highly available server this first in the list.
If the Starttls option is set to true in the LDAP configuration, then the LDAP authentication engine will attempt to use a TLS encrypted path to access the LDAP server. In order for this to work, LDAPS (ssl/tls ldap) must be enabled in the LDAP server and a corresponding certificate must be in place. More importantly, the PathfinderCore PRO LDAP engine must trust the public certificate presented by the LDAP server. If your LDAP server has a publicly trusted certificate, this should happen naturally as PathfinderCore PRO includes the Mozilla trusted certificate root authorities. However, in many cases the LDAP server may be internal only and not have a trusted certificate. In this case it is recommended that the certificate be generated by an internal root authority and public certificate for that internal root be added to PathfinderCore PRO. For example, the following articles describe how to add a certificate authority role to an active directory server and set up a root certificate and LDAPS certificate in Active Directory.
https://pdhewaju.com.np/2017/03/02/configuring-secure-ldap-connection-server-2016/
https://bl.ocks.org/magnetikonline/0ccdabfec58eb1929c997d22e7341e45
Once this is set up, you then need to export the public portion only of the root certificate and add it into PathfinderCore PRO. Click on the security nav bar link, click on the manage certificates link, and then use the add button (+) to add a new trusted root certificate.
Once the root certificate is added, any certificates the active directory server creates based on that root certificate will be trusted by PathfinderCore PRO. You can add additional root certificates or remove root certificates, but you cannot edit them. If editing is required, remove the old certificate and then add the new one.
Once the trust relationship is configured, you can enable TLS in the LDAP configuration and then use the test button again to verify it is configured correctly before applying the changes.
While trying to get LDAP working, it is often useful to get hints as to why the LDAP test might be failing. These hints can be obtained from the sai-ldap-auth log. Click on the logs nav bar link and then the system logs link to find that log. Remember that if the log is open in the browser you need to refresh it to see new messages.
If you incorrectly configure authentication and get locked out of the box, the front panel menu system now includes a Reset Security option.
To access it, tap enter to get to the menus, and then system to find the reset security option. This menu option will reset https to http, set the authentication back to internal, and recreate the Admin user with the default password.
Occasionally after switching from http to https or the authentication method, you may observe missing graphics. This is a one time occurrence after the change based on cached images with different http/https locations. It can be resolved by exiting all instances of the browser and then opening the browser and logging back in again. Since these parameters are usually set up once and then not changed, this should not then re-occur.
Most of the settings within the security section will not automatically sync as they are changed across the cluster. However care needs to be taken that they are set the same on all nodes of the cluster. The reason the sync does not automatically happen is that usually there are certificates that are involved which will be different depending on the host and so must be instantiated first.
It is particularly important that the Device Passwords setting is the same across the cluster. If this setting is different on different nodes, the synchronization of new devices may not obtain the correct ability to login to devices.
It is also important to understand the ramifications of the SapV2 Raw and SapV2 TLS settings when it comes to clustering. Clustering uses the SapV2 protocol for cluster synchronization and so either the unencrypted or encrypted port for SapV2 must be available for clustering synchronization to work. Additionally if the node has the encrypted port enabled, then clustering will only attempt to use the encrypted port for clustering communications. It is highly recommended that you set up your desired security settings and certificates on both servers before setting up the cluster.
If TLS encryption is enabled, the clustering synchronization must be configured to trust the certificates of other members of the cluster. If you are generating certificates using a trusted authority, no further action should be necessary. If you are generating certificates using an internal CA, you need to add the CA's public root certificate to all servers in the cluster, and then the communications will be trusted. If you are using self signed certificated, joining Server B to Server A for the first time when creating a cluster with TLS encryption enabled for SapV2, the join will likely fail and produce a certificate trust dialog:
Clicking Trust will add the public certificate from the other node to the trusted certificate store. Then attempting the join again should work, and after the restart and sync, server B should show the correct clustering state. However, if you then go back and refresh server A’s clustering tab, you will see that the cert state column has a failed link on the A server:
Clicking on the failed link will present the certificate trust dialog again and allow you to trust the certificate from the B server. It should then connect properly. Both servers should now trust each other. This may not be necessary if you are using certificates signed by a publicly trusted authority.
LDAP login tokens are synchronized across the cluster including their removal for inactivity. This means that a successful login to one node in the cluster assumes a successful login to all nodes in the cluster. It is important to note that a redirect due to failure from one server to another is still likely to fail or request a new login. This is because the browser will not forward the cookie and or authentication data to a different ip address or DNS address for security reasons. If you login to both servers in the browser, it will then failover correctly, but that is not ideal and gets lost after all instances of the browser are shut down. To solve this problem, see Floating Ips below.
This version adds a new feature called floating IPs. A floating IP is an additional IP address that you can add to the system which will only be present on one server or the other depending on which server is currently active in the cluster. The IP address will float to the other server if the first server dies. To create a floating IP, access the clustering tab:
Each floating IP must have a unique ID which must be a number between 1 and 255. It is critical to understand that floating Ips use VRRP (Virtual Router Redundancy Protocol) under the hood to manage who should own the IP. Therefore if you have routers in your network that also rely on VRRP, you need to pick id numbers (VRID) that do not coincide with the ones already in use. This synchronization data uses multicast IP address 224.0.0.18 and IP protocol number 112. To create a new floating IP, click the + icon.
Assign a unique id between 1 and 255 for the IP address which will be used for the VRRP id. Enter the floating ip address and select which network interface to use. The host priority list will change to the correct addresses for the cluster depending on the NIC you choose. It is very important that you choose a floating IP that is within the network range of the NIC you choose. In a future version we will add additional cross checking to enforce this rule. If you would prefer the normally used server to be the backup node in the cluster for this floating IP rather than the primary, you can switch the comma delineated order of the list or create the floating IP from the backup server which will cause it to be in the list first. In a future version we will also make this ordering more intuitive with a list where you can move the servers up and down in the order.
Click Apply to Add the IP address into the cluster.
This will now solve the failover login problems because you can point a browser at the floating IP/DNS, and the browser will properly resubmit authentication data/cookies after failing over since it is still the same IP address.
Floating IPs are a little more complicated with https and certificates. If you use self-signed certificates, PathfinderCore PRO currently is not including the floating IPs in the certificate. That will be changed in a future version but that means the self-signed certificate would be regenerated after adding or removing a floating IP to the system.
If you are generating your own certificates using a certificate authority, it is important that the certificate request includes all IP addresses (include the floating addresses) and DNS names you might want to use to access the system.
It is also important to understand how a user panel or other PathfinderCore PRO web page fails over using a floating IP. If the IP is currently owned by ServerA and ServerA fails, the IP will move to B. This will cause a loss of connection in the panel. The panel will then try to reconnect to the floating IP using the WebSocket only. If the WebSocket connection and authentication is successful, it will then refresh the entire panel web page. When using https, this will fail to work properly, if the computer does not trust the certificate on both servers. For example, if you open a browser and go to the first server and get a certificate warning that you have to click through in order to access the page, it is likely the failover to the other server will not work. What will happen is that the NIC icon in the right corner will remain red. If you use the Chrome DevTools(Ctrl-Shift-i) to inspect the webpage data, you will see certificate errors as the WebSocket tries to reconnect. Clicking the refresh icon on the browser will then present the certificate warning from the second server. Once you accept the certificate using the floating IP on the second server, then the panel will fail back and forth correctly. But if you close all instances of the browser that certificate acceptance is lost. The computer/browser has to trust the provided certificate if failover is going to work correctly using https.
Therefore it is highly recommended that if you are going to use https, that you also use certificates generate by a trusted authority and/or use an internal CA with proper trust relationships. If you are in an Active Directory domain, you can use the Domain Controllers as certificate authorities. This will work as long as you have the clients properly configured to trust the domain controllers as certificate authorities and sign your certificate using the domain controllers. Contact your IT department for more information. These issues do not exist if you use HTTP.
This version of PathfinderCore PRO adds a new feature called property groups. This feature allows you to group several properties together for redundancy or synchronization purposes. To add new property groups, visit the new Property Groups navigation bar link:
There are two types of property groups: RedundancyGroups and SynchronizationGroups.
Redundancy groups are used for properties that should usually be in sync and are therefore redundant to protect against device failures. For example, you could wire up a device to the same GPI pins on two different xNodes. In normal situations both nodes would be tripped and Pathfinder would see two reasonably simultaneous closures. An "Or" logic flow could be created to trip off of whichever one came in. But without some complex logic there is the possibility of double processing of inbound signals. Property groups build intelligence into this using a combination of timing logic and (where possible) message ids to create a redundant path, but only process one of the two messages if both are received. An example diagram might look like:
In this situation the output of the PropertyGroup inherits the syntax of the input properties which is supplied to the logic flow editor. The property group handles the logic of understanding whether a new closure is the redundant closure to one on the opposing xNode, or if it is a new closure that needs to be processed. The PropertyGroup then only outputs unique signals. Then the logic flow can just work on the actual functionality that should occur without worrying about the redundancy aspect of the signals.
To create a Redundancy Property Group, click on the Property Groups link in the navigation bar.
Click the plus icon to add a new property group:
Give the property group a name and select Redundancy from the drop down. Case sensitivity determines whether values that are the same except for case should be considered equivalent. For example, in our gpio example, case sensitivity plays a role in whether H is the same as h. The pending interval is the amount of time that an event will stay in the pending state waiting for the recursive event from the other device before being removed. This does not pause the execution of the event, but if the duplicate event from the other device never comes, eventually we should stop waiting for it. If the duplicate event does come, then we clear the pending state but do not indicate the change since it has already been indicated.
Next we need to use the plus icon to add the GPI pin state property into the group. This will present a dialog where several properties can be configured:
The only property that is required is the signal property. The other two are used for very specific use cases where a group of properties are obtained at once and need to be evaluated only when the trigger property is set or when there is additional id information available that the system can use to identify unique events. In this case, set the Signal property to the GPI pin state property of xNode A by clicking the ellipsis button next to the signal property and selecting the Gpio pin. Leave the Id and Trigger properties blank. After selecting this pin state property click Apply, and the new property will be added to the group. Then repeat the procedure with the pin from xNode B. The result will look something like this:
We have basically defined that we expect to receive a pin closure from two different xNodes and to treat them as if they were one signal. The pending interval helps with the underlying logic to track unique cues versus redundantly received cues. Applying the changes to this property group will create the new group in the property groups list:
You will notice that this screen will also show the current value of the property and whether the property from each of the hosts is in sync or out of sync. Out of sync means signals have been received from one device that have not been received from the other.
Once this property group has been created, it can be used as the start point a logic flow by setting the start point to the GroupValue property of the property group.
This logic flow will turn a VMIX channel on and off based on a GPIO closure except that the GPIO closure is fed via redundant sources in case of an xNode outage.
This can be extended beyond GPIOs to any other property in the system. So for example you could set up redundant device emulator paths and pair the resulting watchers from both emulators into a property group.
The output of a property group could also be applied to a Sap Property router. The example below is grouping some device specific meta-data and sending that information into a Sap Property router for distribution to automation systems:
The group state property of the property group can also be used to track redundancy states that are broken by using a delay in a logic flow such that if the property group remains out of sync for more than a certain amount of time, an alarm is raised.
Whereas a redundancy property groups pairs redundant incoming signals, a synchronization group attempts to keep groups of properties in sync. For example you could group to GPO pins together and whenever and one of the pins in the group changes, that same state would be pushed to all other pins in the groups. This could also be accomplished via a logic flow, but this option simplifies the logical combinations when you are trying to keep multiple properties in sync.
To create a Synchronization Property Group, click on the Property Groups link in the navigation bar, click the + icon, and select Synchronization from the type. Give the group a name.
Click the plus icon to add a property. In this case you will just get the property selector dialog.
Add the properties you want to synchronize to the group.
In the example above, changing any pin on this port will cause all of the pins to be changed to that state. Click Apply to apply the changes.
This example could also be extended beyond gpio pins. For example, it could be used to keep VMIX On/Off states in sync between mix engines. Also notice that the GroupState property can be used in a logic flow to alert an administrator about states that remain out of sync for a period of time using a delay in a logic flow.
