Experience with PGP enterprise (v8.02)

6/10/2003
Eric Low

After spending over a week trying to roll out PGP Enterprise 8.02 in our corporatation, I have come to the opinion that PGP (as written by the PGP corporation) is a poorly written piece of junk. Try GnuPG (GPG) with the WinPT frontend instead.

First and foremost, PGP has TERRIBLE support. The ONLY support accessible through their website, www.pgpsupport.com, is a few FAQ's (not even good ones) about PGP and PGP admin, and of course your basic user manuals. They have no forum and no knowledgebase, both of which I feel are essential when you buy a software product aimed at corporations. They have some sort of telephone support, but who trusts that? PGP Also occasionally gets stuck at high CPU utilization (about 50%), and never stops. This usually happens at startup, and for now I don't have time to determine why. I blame it on a badly written product.

The keyserver portion of this product seems to work just fine, but here is my second complaint - you CANNOT install the PGP Admin program on the same computer as the keyserver. If you try, the PGP Apache Service will always fail upon startup (and when you try to start it manually) for inexplicable reasons. Sure, a lot of people like to (or rather, need) to administer their servers remotely, but not me. I like to at least have the option of doing it locally. I could also only find one small sentence about this in the manual, and it is not in an obvious place.

Remember that you must install the PGP Desktop on a computer before you install the Admin program. Once you configure PGP desktop on that computer, you can then create a custom installation program to easily (supposedly) roll out PGP throughout your organization. This is a joke, and here's why.

First, the custom installation still uses many PGP defaults - especially directories specified in the custom configuration. Keyrings are always created in a directory under the My Documents folder (for example, C:\WINNT\Profiles\Administrator\Personal\PGP in NT4 or C:\Documents and Settings\Administrator\My Documents\PGP in W2k) (if you program, that's under CSIDL_PERSONAL in SHGetFolderPath) whether you had defined a different path or not. If for some reason you wanted different users of a computer to share the keyring files (yeah, yeah, security risk, I know), this becomes a problem.
Second, PGP hardly uses the registry to store settings. Maybe this is for security reasons, I don't know. But you are forced to use a document called PGPPrefs.txt, stored two directories under the Application Data folder (for example, C:\WINNT\Profiles\Administrator\Application Data\PGP Corporation\PGP\PGPPrefs.txt in NT4 or C:\Documents and Settings\Administrator\Application Data\PGP corporation\PGP\PGPPrefs.txt in W2k) (In Visual Basic, this is the CSIDL_APPDATA folder in SHGetFolderPath). This CANNOT be changed. You will also find a second copy of PGPPrefs.txt in the PGP program folder, but do not be fooled - this is not used (except maybe to copy settings when a new user logs on, but I have not tested this)
Third, PGPdisk and the PGP installation program have no known command line options. If they have any, there is such poor documentation that it does not matter.
PGPdisk always creates a default file called PGPdisk1.pgd in the My Documents folder (for example, C:\Documents and Settings\Administrator\My Documents\PGPdisk1.pgd in W2k). I feel it should really check the PGPPrefs.txt for a previously mounted pgpdisk volume (DiskMountAtStartupPaths="C:\Documents and Settings\Administrator\My Documents\PGPdisk1.pgd|" (the vertical bar is required)) and use this location/filename rather than just using a default. But it doesn't.
PGPdisk ALWAYS grabs the first available drive letter. In addition, it stores this setting right there in the PGPdisk1.pgd file, so it cannot be changed. Perhaps it can be hex edited, but I assume this would screw up a checksum on the file (if it checks that). Would it really be that difficult to specify a drive letter on the command line? Once again, I think it should check the PGPPrefs.txt file and use the last mounted drive letter there (DiskLastCreateRoot=), especially since both this drive letter and the previously mounted disk filename are stored in the custom installation settings!
Through the server settings, you can tell the custom installation to automatically create a new PGPdisk right after the user creates their initial default key. However, if you had a previously mounted disk specified in the PGPPrefs.txt file with the same filename (see above), PGP will actually try to mount this drive twice, once in PGPdisk and once upon loading PGPtray (the padlock icon in the system tray). This will generate an error stating that the drive is already mounted. Just another annoyance.
When PGPdisk automatically creates a disk, it DOES NOT set it to automatically remount at startup. To do this, it must be specified in PGPPrefs.txt. Custom installation WILL NOT check the path to make sure it exists; so if you had a pgpdisk with the default name/path set to mount on an NT4 machine where you created the custom installation, and you install it on a W2k machine, even if you create the disk with the default name/path, you will receive an error at startup because the path is wrong.
Finally, the PGP custom installation ALWAYS REBOOTS after it is through copying files. It does not even prompt you (it just gives you a 15 second countdown), and there is no known way to avoid this. Again, I feel there should be a simple command line option. Make sure your users have no other windows open before they install!

To get around some of these shortcomings, I wrote a program to run upon bootup, right before the PGP installation could start prompting the user (I put it in the registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce). This program opens PGPPrefs.txt before PGP can get to it and edits some lines (such as the path to the pgpdisk file). In addition, since I wanted the PGPdisk to be drive P: on everyone's computer, it maps every unused drive up through O: to an empty place on the network. It then creates a batch file that disconnects these drives again, which is run after the installation completes (my program dumps another program into the startup folder that waits until the PGPdisk1.pgd file exists and then runs this batch).

Even with my little hacks, installation is still not pretty. PGP Corporation could have saved me days of work by simply allowing a few command line options and throwing a few checks into their installation, but they don't seem in any hurry to provide such basic support. I recommend a different product - perhaps GNUPG (which is open source, so you KNOW will provide excellent support) with the WinPT front-end along with a product like Scramdisk (I have not tried this program, however), which is shareware.

 

Update: 6/12/2003

On some NT 4.0 computers, Windows would lock up as soon as the user typed in their account name/password after PGP installation (even the first time it reboots, in the middle of installation). At first I thought it was a problem with the Netware client, since on some computers it did not freeze if you unplugged the network cable first (and because Netware client is a usual suspect). I did not consider other parts of Windows networking, but they certainly could have been a possibility. Upgrading the client did nothing (and I'm sure downgrading would have the same effect). I found an obscure tip on the net, where some guy was having the same problem and it worked just fine after he switched network cards. I tried the same thing, and it also worked for me. So, then I figured it must be a network card/driver issue. I tried switching network cards, but to no avail. It still locked (although when you uninstall a network card in NT4, NT doesn't always remove the drivers from starting up. It turned out at least one old one from an SN-2000P was also trying to load at startup. I tried disabling it, but same thing).

All of our computers were already at the last Service Pack, 6a, but just in case I tried reinstalling it. This caused even more problems, however, seeing that installation of the service pack crashed ON ALMOST EVERY COMPUTER at about 2/3 of the way through.

Most of the computers crashed with a STOP: 0x00000024 (0x00190201, 0xEF63FA60, 0XEF63F89C, 0X80109F33) (this is the ONLY time I have ever seen this particular STOP error before), on which I had to boot to an alternate install (well, not really. We own NTFSPro, which is the most invaluable tool I have. It's about $300, but if you're in IT/IS, do yourself a favor and spend the money. It will save you hours and hours of trouble every time you crash, since you can boot to DOS and access the NTFS partitions) and copy both C:\WINNT\System32\Drivers\ntfs.sys and C:\WINNT\System32\ntoskrnl.exe from a working installation. On some of those computers I had to copy C:\WINNT\System32\c_1252.nls as well. Then I booted and successfully reinstalled the service pack again (note that all of these are the high encryption versions of Service Pack 6a). Unfortunately, it still froze upon login.

To make a long story short, it turned out that Symantec Antivirus was conflicting with the PGPsdkService service and the PGPsdkDriver driver. I suppose this could happen with other real-time virus scanners as well. If either the PGPsdk service and driver (yes, both of them) OR the Symantec AntiVirus Service were set to manual, login would work just fine. The disabled service could then be started manually (net start "PGPsdkService") with no trouble. Note that when you manually start PGPsdkService, it will also start PGPsdkDriver at the same time. Thus, I set the PGPsdkService to manual, and modified the pgptray icon in the Startup folder to manually start that service right before loading pgptray. I suppose the PGPsdkService could be set to depend on the Symantec AntiVirus Service (with PGPsdkDriver set to manual, of course), so that it would always load PGP after Symantec (and still be fully automatic), but I have not tested this. This seems to work flawlessly now, but is also a bit sloppy and adds even more hassle to the installation. As if it wasn't bad enough! :)

 

Update: 6/12/2003

Since I supposedly discovered and fixed all of our PGP troubles, some people began experiencing strange, seemingly random freezes or blue screens (especially STOP 0x1E or STOP 0x24). On a hunch, I turned off the "Automatically wipe on delete" feature on these people's machines. Presto, I haven't had a problem since. I've been meaning to disable this option corporation-wide, since it's not really necessary for most things we do. However (could this be another PGP complaint??), PGP Administrator will NOT run on any computer where PGP was installed from a custom installation. This is just ridiculous, especially since the so-called "custom installation" is hardly custom at all. I'll get around to uninstalling the custom installation and reinstalling a basic copy on one of our workstations when I actually have free time one of these days <grin>.

 

 

If you have questions or comments about this document, please email Eric Low at elow@datastat.com.