Blog: PGP

I installed Intel Turbo Memory driver update - but it also updated the Intel Matrix Storage Manager & Turbo Memory driver.  After the installation there were two entries in Programs and Features - one just for the Turbo Memory driver and one for the Matrix Storage Manager & Turbo Memory.

After this installation, my PGP single sign-on stopped working.  I would enter a pass phrase at boot and then credentials again when Windows started.  I changed my password to get things synched back up and it still didn't work. [more]

I uninstalled the Turbo Memory driver, after which there is only one related Intel entry in Programs and Features and now it doesn't mention Turbo Memory.  Then I rebooted and still had to use the old Windows password in the PGP boot loader and the new one when Windows started up.  However, this time, when booting into Windows, it gave me a password error before asking for the correct one (i.e., PGP had passed the old one through this time - I could have saved a password change).  After I entered the correct password things worked correct at the next boot.

One of our employees started experiencing regular account lockouts a few weeks ago.  The lockouts started soon after a domain password change.  At boot, and random times throughout the day, his account would just reach the maximum bad attempts and lock.  We checked to make sure he didn’t have any saved credentials under the “Managed Network Passwords” settings of his user account.  The few he had didn’t appear to be related, but after a while we went ahead and cleared them all out.  We checked all his services to make sure none were using his domain account to start.  We also checked scheduled tasks, but none appeared to be the problem.  We thought it might be one of his startup applications, so we disabled all his HKLM/HKCU Run and Startup folder items.  This didn’t fix the problem.  We noticed the account would lockout even before he tried to login, so we were sure it had to be something starting up with the computer (not part of his profile).  The event log kept saying the failure was coming from a stored credentials (though we had removed all the ones we knew of).  We eventually cleared the registry key where all stored passwords are saved, which also caused us to have to remove and rejoin the domain (machine account password probably got cleared).  None of this worked. [more]

We tried to remove all applications we thought might have some old credentials cached.  We removed his ThinkPad fingerprint software, disabled his backup software, removed Symantec.  When none of this worked, I had him decrypt his drive and remove PGP Desktop (multiple day process).  The problems still persisted.  We then booted into safe mode (with networking) to see if the lockout would still happen with a bare minimum of services.  It didn’t.  We ran msconfig to do a “diagnostic startup” (safe mode not in safe mode).  We waited at the logon screen to see if the account would lockout.  It didn’t, so we logged on and began starting services one by one.  (NOTE: msconfig sets services to Disabled, so you must  1) run it  2)set it back to normal startup  3)when prompted to reboot, don’t … then services will be back to their default settings.)  We started a few services, then noticed we actually weren’t on the network because the DHCP service wasn’t running.  We started all network related services and made sure we were authenticated on the network.  We waited to see if what we had brought up so far would cause the lockout.  It didn’t.  We started working through the rest of the services one by one, and eventually two by two.  We finally got to the service “SeaPort”.  The service has no description, but research shows it to be installed alongside any Windows Live “essentials”.  After starting the service, the account locked out.  We played with the service a few times (unlocking, restarting it, unlocking, etc.) to verify it was the problem.  We disabled the SeaPort service and rebooted (with everything else set back to “normal”).  No lockouts!  After a while, we started the service (just to make sure one last time after a clean boot).  The account locked out.  We permanently disabled the service.

I was experiencing long delays when attempting to delete files from my laptop or external USB drives.  For example, deleting a 1.5 GB file would start a continually rotating flood bar of deleting.  It would run for 30 minutes or more before I would give up and click the cancel bar in the dialog window.

The canceling would also present a never ending flood bar lasting 15 minutes or more.  After doing some research regarding an early Vista problem with file moves and deletions I looked at several configurations but could not find the problem.

Finally realized during the installation of PGP desktop I had enabled a secure delete (shred) feature.  When I disabled the shred feature, my never ending delete processes went away.

There is a conflict between some network providers and the PGP password filter that handles keeping the domain password synchronized with the boot password.  Specifically, if you have a Symantec SNAC Network Provider, it can cause a password change to break the single sign-on feature.  What you do to fix it is: [more]

Pull up the Provider Order screen via:

Control Panel -> Network and Sharing Center -> Manage network connections -> Advanced (I had to press and release the Alt key to get the Advanced option in the menu – you may or may not have to) -> Advanced Settings -> Provider Order tab.

Once in the Provider Order tab, I saw PGPpwflt was at the bottom of the list and Symantec SNAC Network Provider was at the top of the list.  I moved the Symantec provider to the bottom of the list which left things like:

This fixed the problem.

Note: This is best done before you change your password!

I had several issues getting my PGP Desktop software to correctly talk to the PGP management server.  First, I went through the default install without any problems.  I configured my private/public keys and encrypted my disk.  I got word from Chris Brewer later, however, that I wasn’t showing up in the PGP server.  We both tried several things to get me in.  I tried importing my private key to the server, but it failed and the log was saying I wasn’t part of the managed domain.  We eventually called PGP support and got my PGP Desktop software reconfigured to use my domain credentials and register with the server.  Turns out I should have done a custom install and targeted our PGP management server… rather than the default stand-alone install.  I was now showing on the server, but I was showing to be decrypted.  My disk, however, was encrypted.  I decided to decrypt and re-encrypt now that I was talking to the server.  This was about a 24-hr process.  After re-encryption and multiple reboots… I still was showing to be “unencrypted” on the server.  The PGP support guy had mentioned the Mac client had some issues reporting properly to the management server and he had  a special build he could let us try.  Once we got it, I installed it and rebooted and everything was fixed.

I had problems with my laptop after installing the PGP desktop (in order to use the PGP Whole Disk Encryption).  Most times, when I would reboot, the PGP boot application would not take my domain password.  I would have to use a one-time recovery token to get booted.  A co-worker found, in the PGP forums, a reference to this being a conflict with the ThinkVantage fingerprint software for some ThinkPads (T400, T500, X301, X200, W700, etc.).  I uninstalled the fingerprint software and the problem stopped immediately.  I ran this way for more than a week without any issues.  I installed the fingerprint software again and, so far, it seems to work.  Time will tell if the problem comes back and the fingerprint software has to be uninstalled again.