File Share Encryption

Hi,

We were planning to setup a encrypted shared folder to be shared across 2-3 departments. Currently we have 2 AD groups and one AD user having access to a shared folder on a system. We have PGP Desktop with File Share Encryption installed on the system having the shared folder.

From what I read through the admin guide, I have done the below so far

• Created a AD user who will add the Group keys and manage the permissions on the folder and the administrator of the folder. This user will be used only for this purpose.
• Created the Group Keys for the AD groups on the Universal Server

So the next step (from what I understood) is to

Log into the system as the AD user and create the PGP key (GKM). This user will add the folder to be encrypted and add groups to the shared folder

There were some issues I needed to clarify which I ran into while doing this.

• Not all the users in the AD group show up in the universal server Group. Only the users which have PGP desktop installed. How do I enroll the users? Does the user have to log into a system with PGP desktop installed at least once and enroll?
• Secondly I tried to enroll a user on a system with PGP desktop but the name keeps showing up as Temporary UserID and I am not able to change it to their name.

Any help would be appreciated. Thanks in advance.

Hi TGBoy,

To access a PGP netshare/fileshare encrypted folder having a PGP desktop is a requirement.

About adding the users to the group, you need to install PGP desktop on the user’s machine and complete the setup assistance and the user will be enrolled.

About the Temporary UserID* Displays in PGP Desktop After Enrollment, please check the below article.

www.symantec.com/docs/TECH177225

HOW TO: Re-enroll Symantec Encryption Desktop for Windows Clients.

www.symantec.com/docs/HOWTO42029

You would need to have Symantec Encryption Desktop on any system where they plan to access the share from.  They will not enroll with the server until they access a system running Symantec Encryption Desktop.

The temporary User ID usually results from the user not having an email address entered in AD.  We pull that data as a part of the username for the account on the Symantec Encryption Management Server.  Make sure those users have an email address listed on their AD account, then do the following:
1. Right-click on the PGP tray icon, and select Exit Services (if not enabled per policy, you can go into Task Manager and kill any processes marked PGP)
2. Go to %appdata% for the user
3. Enter the PGP Corporation folder
4. Rename the PGP folder to PGP_OLD or something else other than PGP
5. Start Symantec Encryption Desktop and it should prompt you to restart all PGP services
6. Re-enroll the user when prompted

That should get the email address straightened out and have the keys assign properly.

Thanks for your replies. Regarding the TemporaryUserID, the email addresses are present for each user in AD. The managed domain entered in PGP is corp.company.com (which is how our domain is in AD) but the emails start with company.com. In the username field of each key for the *Temporary UserID* the username is saved as username@corp.company.com. What would be the managed domain to be entered - corp.company.com or company.com? Or I should enter both?

Guess it wasn't deployed correctly in our environment, since almost all the user's names under Managed Keys is *Temporary UserID*

Will I have to re-enroll all of these users? What happens to the WDE for the user's systems? Decrypt and re-encrypt with new keys?

Thanks in advance.

I would enter both entries under managed domains, and check the results of re-enrolling a user.  If the email address doesn't match a managed domain, but the user is clearly in that domain, it would probably still generate a temp key, since the email doesn't match the user's domain.

It may overwrite the existing keys' user information/data, effectively changing them to a normal rather than temporary key.  This may work without having to re-enroll the user if they are SKM keys.  It isn't a commonly encountered issue so I really don't have much relevant data on whether or not it will require re-enrollment.

Thanks. I will try this and update you.