Recently, I needed to log into the console of our PGP Universal Server to verify the version level of Apache installed. Unfortunately, the Universal Server is (intentionally) locked down since all the tools required to manage the server are built into the web console. When the server is initially installed, you do not have access to log in via SSH or through the console because of the locked nature of the kernel. (Sidenote: there are supported ways to set up SSH access through the use of private keys). Fortunately, since the server is based in Linux, it’s trivial to “break in” and get access to the console. All that is required is physical access and some downtime. [more]
Step 1: Reboot the server
Step 2: When Grub loads, interrupt the auto-boot sequence and press ‘a’ to edit the kernel arguments before booting
Step 3: Add a space and the word “single” (lower case) to the line and press enter.
Step 4: Enjoy your root access.
As most know, when using PGP to encrypt a hard drive, you enter your password at the boot screen and it will log you into Windows. After redeploying a laptop for a new user, PGP would not pass the new username thru to Windows. It would stop at the Windows credential prompt with an previously used username. After a fair amount of troubleshooting and research, it was determined the problem was with the TPM chip.
PGP can be configured to use password only or TPM and password to authenticate users. PGP on this laptop had been configured to use TPM and password. The TPM chip had become locked out by the previous user. Which prevented new users from accessing the TPM chip. So you could add a new user to PGP but it never would add the user to the TPM configuration and there was no error stating this. Since the old user’s password was not available, it required deactivating the TPM chip. Before deactivating TPM, the administrator account being used changed to password only in PGP. If this change wasn’t made to the administrator account first, it would have locked out of PGP. TPM was deactivated and the laptop rebooted. TPM was reactivated and the laptop rebooted. The new user account was added back to PGP and rebooted again. This time PGP passed the username through to Windows without any problems.
A few weeks ago, I was asked to set up scheduled reports for PGP Endpoint. These weekly reports would include information such as devices blocked or allowed and would be emailed to a small subset of administrators. After setting up the report and using my email address as a test, I waited for it to send. It didn’t send. I changed the report to save to a file to troubleshoot and it wouldn’t do that either. Time to call PGP.
The engineer assigned to my case didn’t have much experience with PGP Endpoint and, as such, took a bit longer to research and get back to me than was normal. After sending him the debug logs, he got back to me saying that the license key was invalid and to double check that I had a licensed installed. [more]
Yup! From the main screen of the management console, there it is…
Fast forward to a week and a half later, and I get another email from my engineer. “Make sure that there are no characters in the report template name that cannot be in a Windows File Path.” Wait, what?
Sure enough, my template names included a “/” in the template name. Take that out, and everything works fine. It turns out that this scheduler generates the report, using the template name as the file name, and saves it in a temporary location until it can attach the file to an email and send it off. What was happening is the scheduler would save the file in a location that doesn’t exist (because of the “/”), turn around and try and attach the file (that doesn’t exist) to an email and fail, and then try and send off an email (that doesn’t exist because the previous process failed). And then report that the license file was invalid.
To add another layer of humor to this problem, take a look at this list of templates. The ones with red arrows have NOT been modified since the initial installation of PGP Endpoint. Notice anything peculiar about the names?
I recently moved a hard drive from a ThinkPad T60 laptop to a ThinkPad T400. The hard drive had a BIOS password set, but it appeared to work normally in the T400. I could boot, enter the hard drive password, and access the disk. However, when I started having problems getting PGP to encrypt the hard drive, I decided to remove the hard drive password. The T400 could not remove it – the option was grayed-out in the BIOS. Luckily, I still had access to the T60, so I put the hard drive back in the T60 and was able to remove the hard drive password. I have now moved the hard drive to the T400 and I am able to set/remove the hard drive password at any time.
I had recently upgraded a Mac user to the v10 PGP client and registered them with the bank's PGP Universal Server. Everything seemed to work fine, but the user later discovered that PGP would prevent them from shutting down their machine if their iPod was attached. Other devices didn't seem to affect the shutdown process. I did some research and found this was a known issue. The fix was to simply update the client from v10.0.0 to v10.0.2. Obtaining the v10.0.2 update proved to be trickier than expected, but with a coworker's help I was able to download the update and put it on my USB thumb drive. With update in hand, I strolled over to the bank and quickly installed the update off my USB drive (ensuring the customer this simple procedure would fix their problem). When the computer rebooted, I pulled my thumb drive out and waited for the PGP screen to come up. When it did, I had the customer enter their PGP Wholedisk passphrase. After a couple of failed tries, PGP accepted the password and began to load OSX. Then, the OS crashed!
The user told me that happens sometimes after he misses his PGP password, so he simply restarted and tried again, this time putting the password in correctly the first time. It ended the same way however. At this point, the room became very hot and I started to sweat profusely. I was sure I had just trashed this guys' machine by applying this simple update. I'm sure he was starting to think the same thing too. I sat down at his machine, wondering what in the world my next step was going to be, and then it hit me. "I wonder if PGP needs something off the installation media (my USB drive) to update the boot process?" I shut down the machine, plugged my USB drive back in and powered it back on. I logged in to the PGP screen, the OS started to load...loading....loading....loading... OSX login screen! Suddenly, the temperature in the room dropped drastically. I had the user log in, I removed my USB drive and rebooted again. Everything came up perfectly.... much to my relief. [more]
One other note about PGP and OSX upgrades...
In some cases, PGP will modify the system partition table enough that OSX upgrades (in my case, Leopard to Snow Leopard) won't be able to identify the currently installed OS. This makes doing an in-place upgrade impossible. The fix is to simply open Disk Utility, select the system disk, select the Partition tab, resize the system partition by dragging the bottom right corner up, then right back down (this should enable the "Apply" button), click Apply (confirming the change), exit Disk Utility. The OSX upgrade should be able to correctly identify the currently installed OS after this.
I installed PGP on my new laptop and after the reboot I got the PGP prompt for my passphrase. This was a new laptop and was not yet encrypted so I was a little confused where it got a passphrase since I was using BitLocker on my old laptop. Then logging into the PGP Universal Server I remembered I used PGP to encrypt a different laptop while we were testing. PGP carried over the old passphrase, and of course since it was installed on a test laptop I didn’t remember (or record) the passphrase I used. I removed my user and computer entries in PGP and was able to install and encrypt after wiping the partition table and reinstalling from the factory default image.
Secunia is one of the many security firms who maintain teams of researchers looking for vulnerabilities in software applications. I have seen their name credited on several vulnerability notices from CERT and SANS. They offer a software vulnerability tool called Secunia Personal Software Inspector that is free for personal use. It scans your system looking for all executable files and then compares them to their database of current software versions/vulnerabilities. I have used it on a couple of systems that I believed to be current and found at least half a dozen out-of-date or vulnerable apps. Apart from the security benefits, it can also be an easy way to see if there have new releases for any of your software. For example, Secunia PSI informed me that a new version of Wireshark was available for my home computer even though it didn't find any security vulnerabilities for the version I was using. This can be much easier than individually opening each app and clicking on "check for updates", or even worse, having to go to the app's website to see if a new version is available.
There was a conflict between the Lenovo fingerprint software and PGP whole disk encryption on T400s and T500s. If the Lenovo fingerprint software is installed, using your domain password at the PGP boot prompt didn't work and you could lock yourself out. You'd have to use a one time password to boot.
Under Windows 7, fingerprint drivers are native and, if you enable the fingerprint reader and enroll your fingerprints, it works fine with PGP WDE.
We had a new printer that needed to be installed on a PC at a customer site. The new printer was USB and after setting it up, all of my test jobs that I sent to the printer failed. I tested out many different drivers and even tried using a different USB printer at one point. None of these things worked. I then finally decided to remove PGP endpoint protection and the printer started working immediately. This didn’t make much sense because my account was not supposed to be blocking anything through PGP. I checked the PGP settings and found that the “everybody” group (a distribution group setup at the bank which did not include my account) was given access to these “other devices” that this USB printer fell under the category of. The group that was meant to be there was the “everyone” group to which includes CoNetrix accounts. This wasn't an easy problem to solve due to the lack of a useful error message. If you use PGP endpoint protection be aware that you will not get an error message if it's blocking your printer and that USB printers fall under "other devices".