Security Issues on Redundant Servers

[Tanquen]

When I try to log into ViewX with the superuser account when both servers 1 & 2 are running it only seems to works on server 1. I thought someone had changed it on server 2 but when server 1 is offline it works.

So even though server 1 is active and I’m running ViewX on server 2 it’s like it’s looking to server 2 for the account and it’s wrong? Or server 2 can’t get the correct account info from server 1? But the account is the same on both.

When using the server configuration I can only log into the local server with the superuser account. When I try to connect the remote server it say the account is not correct.

With a regular user account in ViewX I can be logged in and force a failover and after the failover it logs me out saying the account or password is bad. Are the accounts not synced up?

Did IT lock down some ports that ClearSCADA needs?

[BevanWeiss]

My understanding was the following:

The superuser account was specific to a server.  The username/password hash was stored specifically in the Registry on the server in question, and it was not synchronised between servers.

I don't believe this has changed in recent versions of GeoSCADA Expert either.

However... there was a change in CS2017R2 I believe (I think it was related to the Secure Connection stuff) that the 'superuser' account was not going to be allowed to connect remotely.  I think what this means is that you would need to be using a ViewX session from 127.0.0.1 local to the server to utilise the superuser account.  Which absolutely makes sense.  After all, you should NOT be using the superuser account.  The Server Status tool even tells you this.

I don't believe I've really tried otherwise.  I almost always have a proper user account for development, even normally when developing locally in a VM.  The only time I'd tend to use the superuser account is when launching up a database locally that I don't have a user account in.

When you mention about the 'regular user account' being logged out and not logging back in on server failover, this does sound like a synchronisation issue.  Or, it might be something else.  Like the server configurations for External Authentication don't match.  Are you using Windows AD for the user?  I could imagine an issue if using LogonUser, and one of the servers wasn't a member of the domain.  Or if using LDAP, and one of the servers wasn't configured to use LDAP correctly.

[Tanquen]

Had an issue when I tried to failover to the backup server and after that no setpoints worked. They all had an error saying the item is in the wrong state within current server. It also logged me out saying the account was not correct. That is when I tried the superuser.

I don't like using the superuser with the seemly instant logout.

What is the best way to resync? I stopped server 1, copied the application folder, restarted server 1 then stopped server 2 and put the copied application folder on server 2 and restart server 2. Then tested a failover to server 2 and that worked with no more setpoint errors. I then failed it back over to server 1.

I did not retest the different user accounts but I think they are just ClearSCADA accounts and not active directory. I don't think they are even on a domain.

[BevanWeiss · Accepted solution]

There shouldn't be any need to manually perform any 'resync' operations.  If the Standby server is connected to the Main, then it should automagically be in sync.

If you've done some questionable activities on the Standby server (like David Skillbeck was talking about with manually moving historic files around) then you might end up with inconsistent data files.  The cleanest way to get them back to consistent with the main server is to just go into the database folders and delete them on the Standby (after shutting it down).  Then when you load back up the Standby server it will connect to the Main and retrieve all the config, the data and the history.  Depending on your database size and amount of historical records, this could take quite some time.

If you failed over to the Standby server, and setpoints didn't work, then perhaps there was an issue with the network connectivity from the Standby to the field devices.