Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Changing key management on existing consumer policies.

Created: 25 Sep 2013 • Updated: 02 Oct 2013 | 3 comments
This issue has been solved. See solution.

Experts,         

       I made a mistake in creating a bunch of consumer policies on the universal server, the mistake was with the setting the wrong key modes for these policies. I want to now change the users keys from Guarded key modes (GKM) to Server Key Modes(SKM). The main reason for this is so that the key password is always in sync with the AD credentials and the password is synced automatically VS manually.

What would be the impact of just going into the policy, un-checking the GKM key mode and checking the SKM mode? After applying such a change, would users key change transparently or would they need to be deleted and reenrolled?

The folders are encrypted to a group key so deleting the users key should not impact their access once the new key is created, I would hope. We also don’t allow users to create their own net shares to their own key so new keys would not be an issue there as well. Can anyone give me some tips on how to do this transparently if possible?

Operating Systems:

Comments 3 CommentsJump to latest comment

Japke's picture

Switching key modes from GKM to SKM will be done on the client side. When you update the respected consumer policies on the server to switch the key mode, and save the changes. The next time the client updates its policy it will prompt the end-user the key mode has changed. And since you are going from GKM to SKM it will probably ask the end-user for the passphrase of the current GKM key (if it is not already cached) and change the key to SKM.
There should no reason in this change to re-enroll the clients.

Since the change is per consumer policy, you can easily setup a test user with a separate test consumer policy and see the change happening when updating the policy on the client side.

Note, if you want to roll back from SKM to GKM (or CKM), you will need to be on version 3.3.0 MP3 / 10.3.0 MP3 or higher for it to work correctly. See the following article on that:
BUG REPORT: Key Mode Change from SKM to CKM/GKM Prompts for Passphrase when PGP Services are Restarted
http://www.symantec.com/docs/TECH193051

I am no longer a Symantec employee.

3L3M3NT's picture

Thanks for the info Japke.

            I will now test this key change on my end using the new 10.3.0MP3 client and server versions. The only thing that still bugs me, and really, the whole reason I want to change from GKM to SKM is because the GKM key will not automatically sync the AD password changes like the SKM key does. Most of the users have completely forgotten what password was set on this GKM key when they were first enrolled. Those users will need to have their current GKM keys deleted and be forced to re-enroll with a new SKM key policy.

            I started noticing these problems when users’ machines were being serviced and reimaged. Some users were typing in their current AD password for the PGP enrollment passphrase and this would not work. Some users remembered their previous passwords but the ones that didn’t needed to be forced to re-enroll in order to create a new key. This is obviously a manual process that includes deleting keys and cached info on the local computer level. Lucky for me, I only have about 30 users currently using this GKM key, just want to get it converted ASAP.

Thanks for the info about the bug report as well. Take care.    

Japke's picture

Just a comment that popped in mind - and I seem to have forgotten to add it before. The SKM key does not have the same passphrase as the AD account. The passphrase on the SKM key is a random passphrase managed by SEMS. And in turn SEMS arranges access to this key / random passphrase by the AD account, so you will only need to use your AD account passphrase to unlock the SKM key.

Since you are using group keys for NetShare / FileShare, the user experience is similar to that of an SKM key mode user (no user passphrase is needed to be entered by the user directly), although a different operation is performed in the background. (there is for instance no offline mode for group keys - while SKM has an offline mode)

Symantec Encryption Key Modes (formerly known as PGP Key Modes)
http://www.symantec.com/docs/TECH149029

SKM keys are generated and managed on SEMS. SKM keys are automatically managed for the user by the client and SEMS--no user intervention is needed to use SKM key modes and no passphrase needs to be entered in order to decrypt and sign data.

In Offline SKM mode, the private key is stored on SEMS, as well as the client, however when the SKM key is on the client, it is protected with a random passphrase that is unlocked when the user authenticates when logging in to their Windows account.

I am no longer a Symantec employee.

SOLUTION