Kaspersky
Solved

Kaspersky Security Center 13.2 Upgrade - Parallel Migration

  • 25 November 2021
  • 10 replies
  • 94 views

Dear All,

I am working for a MSP. We are managing several Kaspersky Security Center systems for our clients. We in the process of standardizing the KSC implementation (version, configuration and SOPs). Most enviroment requires an upgrade. Managed to upgrade some of the systems to the brand new KSC 13.2 successfully. 

Next week, I am planning to upgrade an enviroment from KSC 12 to KSC 13.2. Right now, the KSC 12 is installed in a domain controller together with local MS SQL instance where there KAV DB resides. To clean-up the mess, I prefer to decommission the domain controller by installing a new domain controller. For the KSC, I prefer to install KSC 13.2 in a brand new VM. Once the server is ready, I will be using the “Switch administration server” group task to move the existing clients from the old KSC server to the new KSC server.

In a normal situation, I believe the migration plan should works well. However, I have one blocking point for which I would like seek clarification from the Kaspersky community. 100% of PCs that are managed by the KSC 12 server are encrypted through Kaspersky. 70% of the PCs are encrypted with Bitlocker and the rest are encrypted with Kaspersky’s native encryption tool. From the documentation, I understand that Kaspersky allows exporting and importing of encryption keys from 1 administration server to the other.

I would like to understand if exporting and importing the encryption keys from the current server to the new server would allow me to decrypt the computers and the external USB drives from the new server. The support team uses the “grant access in offline mode” function to provide assistance for the users whenever the users forget their PIN/Password.

Your feedback and comments are most welcome. Thanks for sharing your thoughts and comments.

icon

Best answer by MilanBortel 3 December 2021, 11:08

View original

10 replies

Userlevel 4
Badge +2

Hi @Kumar_K,

from my experience it works fine. I personally did it this way:

  1. back up old KSC
  2. install new KSC on new host
  3. restore backup from old KSC (after this step, all encryption/decryption keys are present on new KSC)
  4. reconnect all hosts to new KSC (change administration server task or reinstall Network Agent with new connection settings)
    Change Administration Server task

     

tadaaaaa :cowboy:

Let us know, if you have any further questions

Cheers,
Milan

Hi @MilanBortel 

Thanks for your response. During the transition phase (the gap between backup restoration and switching admin server) if there is a change in the encryption key, will the client updates the new server when it connects to the new server? The change in the recovery key happens when a user forget the Bitlocker PIN. 

Userlevel 4
Badge +2

Hi @Kumar_K,

when you forget the BitLocker PIN, you have to enter the recovery key:

BitLocker recovery key prompt

This is the MMC interface:

BitLocker recovery key

After successful boot, user is prompted to change the password:

BitLocker Change password prompt

After password change, both recovery key and recovery key ID are updated on KSC side:

KSC - BitLocker recovery key and ID has been changed

If KSC backup has been made prior to this update, I’d assume that the new recovery key won’t be available after restore in new KSC.. haven’t tested that scenario, though.

 

So, my recommendation - the migration process should take place either over night or during weekend, where the risk of this inconsistency would be minimized. Anyway, you can run both old and new KSC for few days after migration and keep backups to be able to restore access to encrypted drives if that occured during the migration process.

I believe that you do have documentation of this, right? To be able to say which user has asked for which recovery key at what date/time.. :grinning:

 

Cheers,
Milan

Hi @MilanBortel 

Thanks for the detailed description. Yes, I can request our helpdesk to keep track of such requests from the users.  For such scenarios I could just simply decrypt and re-encrypt those computers in the new server. The full disk encryption should be find. But my fear is is about the encrypted USB drives. We have enabled USB drive encryption in portable mode. We have no control over the number of USB devices the users own. The USB drives can also be their personal device. If a user encrypt a new USB drive during the transition (it should be that long, 2-4 hours at max) there is a chance to loose that particular key right? I tried to discover the KSC reporting but there is no option to generate a report on when a USB key was encrypted.

I noticed that, there is an option in the KSC server’s properties to export and re-import Encryption keys in a new administration server but I don’t its doing anything at all. I tried to re-import the keys in a staging KSC server (clean instance) but I can’t see any information about encrypted drives post import process.

Userlevel 4
Badge +2

Hi @MilanBortel 

Thanks for the detailed description. Yes, I can request our helpdesk to keep track of such requests from the users.  For such scenarios I could just simply decrypt and re-encrypt those computers in the new server. The full disk encryption should be find. But my fear is is about the encrypted USB drives. We have enabled USB drive encryption in portable mode. We have no control over the number of USB devices the users own. The USB drives can also be their personal device. If a user encrypt a new USB drive during the transition (it should be that long, 2-4 hours at max) there is a chance to loose that particular key right? I tried to discover the KSC reporting but there is no option to generate a report on when a USB key was encrypted.

I noticed that, there is an option in the KSC server’s properties to export and re-import Encryption keys in a new administration server but I don’t its doing anything at all. I tried to re-import the keys in a staging KSC server (clean instance) but I can’t see any information about encrypted drives post import process.

Yeah, @Kumar_K

the option to import Encryption keys IMHO means that the new KSC server would use the old KSC’s master encryption key and thus being able to manage all external encrypted drives.

You know, with KSC installation, there are always SSL certificate and master keys for FDE and FLE generated..

However, if you restore the backup from old KSC to new KSC, all the keys and certs will be restored, so I would fear no more.. I think external USB will work just fine with the new KSC :innocent:

 

Cheers,
Milan

Hi @MilanBortel 

Thanks for the quick response. Just to make sure that I understand the process correctly, you mean the new KSC server must have the SSL certificate and master keys for FDE and FLE of the old server (through backup restoration) before I can test the encryption key export and re-import procedure?

Userlevel 4
Badge +2

Hi @Kumar_K,

well, I think that after restoration of the old KSC backup on the new KSC, there is no further action needed. All the keys will be restored and available. So you will just move all the computers to the new KSC.

One more thing came to my mind. On the computers KES stores these encryption/decryption keys also locally, so they could work offline (with no KSC connectivity). And after you move the computers to new KSC, they will sync these keys with KSC if they are missing.. does it make sense to you? :stuck_out_tongue_winking_eye:

Milan

Hi @MilanBortel 

Thanks for your response. Just completed the backup restoration in the new server. The restoration process went well but post restoration, I was not able to connect to the administration server through console. I noticed the following error messages in the event log. Any idea on how to solve this? 

 

Service 'kladminserver' has been stopped due to an error. #1950 (102) Generic db error: "102 'Incorrect syntax near '('.{42000};' LastStatement='EXEC grp_sync_subgroups'"

Stop due to error. #1950 (102) Generic db error: "102 'Incorrect syntax near '('.{42000};' LastStatement='EXEC grp_sync_subgroups'"

The problem was caused by the database compatibility setting. The support team assisted me. Changed the compatibility from 2008 to 2019 and that solved the problem. 

Userlevel 4
Badge +2

Hi @Kumar_K,

great it all worked out :wink:

 

Take care,
Milan

Reply