logo
Powered by QM on a Rpi server

Support Call 00871

Show open calls
Opened  16 Jul 18
Closed   
Priority
Accrued time  00:00
Charge  Unchargeable
State
Fixed at   
Version  3.4-12
Licence  0239183129
Platform  Linux
Issued  08 Apr 09
Company  Applied Concepts, Inc.
Contact  James Woods
Charge to    Ladybridge Systems Ltd
Submitted by  James Woods
Email  james@a-concepts.com
Summary   
Detail 
        Chargeable?Set waiting support
18 Jul 18 11:18:25
Outgoing
Edit
I have done a quick test and adding GRANT.KEY and REVOKE.KEY to the list of replicatable commands is an easy change. It does, however, have a potentially serious security issue in that the master key will be displayed on the screen when the command prompts for it.

This is because account replication is built on the QMClient API and this only supports simple input, not the options such as HIDDEN that the client side is using when prompting for the master key.

We probably should look into a change to QMClient to support the options available with INPUT but this may require a significant rework of how input is handled internally and is therefore not going to be quick to implement.

If you don't see the visibility of the master key as a problem, let me know and I can let you have a patch that adds these new commands.
17 Jul 18 14:52:43
Incoming
Edit
I understand. I will delete the vault on the replicated machine and re-cre=
ate the key.

Thanks for the clarification.

-----Original Message-----
From: support@openqm.com [mailto:support@openqm.com]=20
Sent: Tuesday, July 17, 2018 8:47 AM
To: James Woods
Subject: OpenQM Support Ticket 00871

DO NOT CHANGE THE SUBJECT LINE IF YOU REPLY TO THIS EMAIL

The RESET.MASTER.KEY is needed because the key vault itself is encrypted in=
very complex way that is dependent on many things including the licence nu=
mber and system id code. This was done so that someone stealing a backup ta=
pe and restoring it on another QM system would not get access to the encryp=
tion keys without knowing the master key.


You can review this support call online at http://www.openqm.com?t0=3Dsuppo=
rt4&t1=3D00871&t10=3D0239183129

Thank you,
OpenQM Support
17 Jul 18 14:46:42
Outgoing
Edit
The RESET.MASTER.KEY is needed because the key vault itself is encrypted in very complex way that is dependent on many things including the licence number and system id code. This was done so that someone stealing a backup tape and restoring it on another QM system would not get access to the encryption keys without knowing the master key.
17 Jul 18 14:02:37
Incoming
Edit
I did a copy of the vault, and did not do a RESET.MASTER.KEY (both the prod=
uction and replication system's vault have the same master key). I didn't k=
now about shutting down the replication phantom.=20

When I did a LIST.KEYS, it asks for the master key, then all the folks who =
are on the production system are listed with the appropriate key in the rep=
licated system.

But you're saying this will not work?

-----Original Message-----
From: support@openqm.com [mailto:support@openqm.com]=20
Sent: Tuesday, July 17, 2018 3:23 AM
To: James Woods
Subject: OpenQM Support Ticket 00871

DO NOT CHANGE THE SUBJECT LINE IF YOU REPLY TO THIS EMAIL

I will look at adding GRANT.KEY and REVOKE.KEY to the list of replicatable =
commands.

With my suggested work-around, the RESET.MASTER.KEY would have to be done a=
fter every copy of the key vault so it is probably not a very practical sol=
ution. Also, it would be necessary to shutdown the replication subscriber p=
hantom during the copy and key reset. Not one of my better ideas!

More news when I have looked into adding these commands.



You can review this support call online at http://www.openqm.com?t0=3Dsuppo=
rt4&t1=3D00871&t10=3D0239183129

Thank you,
OpenQM Support
17 Jul 18 09:23:18
Outgoing
Edit
I will look at adding GRANT.KEY and REVOKE.KEY to the list of replicatable commands.

With my suggested work-around, the RESET.MASTER.KEY would have to be done after every copy of the key vault so it is probably not a very practical solution. Also, it would be necessary to shutdown the replication subscriber phantom during the copy and key reset. Not one of my better ideas!

More news when I have looked into adding these commands.
16 Jul 18 17:36:05
Incoming
Edit
Hi,

I think it should be an option. I don't quite see the reduction in securit=
y, but a do see the error prone process to keep two separate security syste=
ms up to day. As users are added and deleted, or security for those users =
change, it means that you have two systems that have to be manually updated=
.

In the copying of the $VAULT file and the RESET.MASTER.KEY, would the RESET=
.MASTER.KEY need to be done at each copy? We would probably opt to copy ni=
ghtly, which would make the RESET.MASTER.KEY a manual process that would ne=
ed to be done daily.

James

-----Original Message-----
From: support@openqm.com [mailto:support@openqm.com]=20
Sent: Monday, July 16, 2018 11:14 AM
To: James Woods
Subject: OpenQM Support Ticket 00871

DO NOT CHANGE THE SUBJECT LINE IF YOU REPLY TO THIS EMAIL

Hi James,

We chose not to do this as part of account replication as it slightly reduc=
es system security, however, I am open to arguments that it would be useful=
.

As a quick temporary work-around, you could copy the $VAULT file using an o=
perating system level copy tool and then use RESET.MASTER.KEY with the same=
master key as on the primary system. Messy but it will work. It will, howe=
ver copy the entire key vault rather than having any control over which GRA=
NT.KEY actions get replicated.


You can review this support call online at http://www.openqm.com?t0=3Dsuppo=
rt4&t1=3D00871&t10=3D0239183129

Thank you,
OpenQM Support
16 Jul 18 17:14:02
Outgoing
Edit
Hi James,

We chose not to do this as part of account replication as it slightly reduces system security, however, I am open to arguments that it would be useful.

As a quick temporary work-around, you could copy the $VAULT file using an operating system level copy tool and then use RESET.MASTER.KEY with the same master key as on the primary system. Messy but it will work. It will, however copy the entire key vault rather than having any control over which GRANT.KEY actions get replicated.