File Share Encryption

I have deployed PGP WDE to several users and came across a problem with the single sign-on ability.  Most users (that I know of), including myself, are able to log into the BootGuard screen and get into Windows without another login or error.  Some users receive an invalid login error when it tries to pass through to the domain.  The really odd thing is that their LDAP credentials are the same as their domain credentials.  The Force option is set on the Universal Server for "encryption of disks to existing Windows Single Sign-On password."  Any ideas as to why this is occurring?

This Knowledge Base Article might be helpful.

What do you mean by "their LDAP credentials are the same as their domain credentials" ?

that´s the normal behaviour, domain\user + password works for both BootGuard and Windows login.....

I didn´t get the problem..

I went through all of the potential fixes on several different computers with colleagues in IT.  None of the fixes worked, but I will say that I was unable to perform the check for the PGPWDE01 (first option).  All of the computers in our IT dept. that I checked received errors that access was denied.  Although we are all in the Administrators group, I logged into the pre-boot PGP screen with the PGP Disk Administrator passphrase, then into the computer with the local admin. account.  The result was the same.  We are under the impression that PGP is preventing us from from modifying the file in any way whatsoever.  Any idea why we're having that problem or, more importantly, do you have any other possible solutions?

Hello again Julian.  I'm not clear on what you mean either.  There is an option on the Universal Server to foce, deny, or allow single sign-on with the Windows password.  Since the initial registration of the clients to the Universal Server uses LDAP (for us, Oracle LDAP), I could choose deny for the single sign-on option, right?  By doing this, my assumption is that a user's PGP login passphrase would be the same as their LDAP credentials.  Following this, they would have to enter their domain/AD credentials.  By using force, our intention was to sync the PGP login password to the domain (via AD).  This would allow our users to enter their password one time.  The problem I'm seeing is that an error is frequently encountered after the first login indicating the username or password is incorrect.  I say frequently, because it doesn't happen every time for every user.  It's intermittent, which really doesn't make sense.  Any help you may be able to offer would be greatly appreciated.

Well sometimes user needs to logoff and logon after changin domain password, so WDE refresh its password.

There is also an interesting troubleshooting guide:

http://www.symantec.com/business/support/index?page=content&id=TECH149470&actp=search&viewlocale=en_US&searchid=1326290818223

This has been ongoing for weeks, so logging off and back on hasn't helped.  The article you sent was the same one that Tom sent me.  It was very interesting, and I was very hopeful one of them would remedy the problem.  As I said previously, none of them worked.  They were tried on multiple computers with different users.  There was one exception.  I couldn't see the permissions for the PGPWDE01 file.  If you look at my previous response, you'll see those details.

I'm creating this reply with hopes to initiate an update on this problem.  It is apparent that a number of clients are affected, so I would expect Symantec to be working on a solution and providing updates.

are these cloned systems?

Have you updated server/clients after encripting drive?

can you make sure they log to bootguard using the correct domain ? (in case they have the option to choose domain during logon)

No, these are not cloned machines. 

Yes, I have updated the server/clients. 

User do not have the option to change the domain at BootGuard.

This isn't an isolated incident as I found another forum discussion on your site.  There are other companies experiencing the same problem.

Here is the other forum discussion I mentioned.

try running pgpwde --update --disk X so WDE gets updated according to the new version.

If does not work, try re-encripting the drive

I've done both of those.  From what I've been reading, this is a bug that Symantec needs to address.  Again, this isn't an isolated incident as you can see from the other forum I linked to.  Thanks for your help anyway.  I guess I'm looking for a fix more than troubleshooting as everything has been setup according to direction from Symantec.  I actually met with two Symantec employees that came to my office to assist me.  Everything was setup properly.  The problem is with PGP itself in some regard.

Glad to hear that.

Do you think you can share the solution ?

Sorry to confuse you.  I do not have the solution at this point.  The guys that were here looked at the console and confirmed the configuration settings.  This was at the tail end of last year, but the problem still persists.  I just thought Symantec would have addressed the problem by releasing a patch for the product.

We have been battling this issue for over a year (or maybe more) without resolution.  It was rare on Windows XP but became more pronounced when we started to roll out Windows 7.  All of our machines run 9.12.1035 WDE only and none of the later versions that we have tested have resolved the issue.  The last update I had on our open case was that with Windows 7 there is a timeout period when the token that PGP has will expire.  We use a banner text on login and if users aren't quick enough (or even if they are and the bootup takes a while) SSO login will fail and they will be prompted for their password.  Symantec is aware of the issue and has been able to reproduce it in their lab however the timeout may not be something they can fix since it’s a Windows thing.

The other issue that we have seen is with the Altiris agent (NS6), it's related somehow.  In my testing I had 100% successful SSO logins in over 25 reboots without the Altiris agent installed on a clean build of Windows 7(MSDN).  Once I installed our Altiris agent I immediately had SSO failure.

They are still looking into this issue and neither are reported to be fixed in the MP4 version that was just released.  It's not really a problem or hindering the use of the product, just a nuisance really.  One that I would like to have resolution to or a definitive answer that it’s expected behavior so I can set the expectation for our end users.

Thanks for chiming in Jonathan.  I currently have an open ticket with Symantec, but there are no known resolutions.

Recently, it was discovered (internally) that the cause of the problem may be due to the a legal disclaimer that comes up after the BootGuard login.  Once a user clicks OK to acknowledge the message, an error is encountered indicating the username and/or password is incorrect.  We're still testing, but it looks like this could be the cause.  If the registry keys for the disclaimer are deleted, the problem goes away.  When they are put back into place, the problem arises again.  The question remains of whether to live with the inconvenience or remove the disclaimer.  Nonetheless, I would expect Symantec to address the problem as many companies use such legal disclaimers.

I'll definitely keep the Altiris Agent in mind.  Thanks for sharing.

I have seen other third party programs that attach themselves to the network provider list conflicting with our SSO feature as well. You may wish to check for Intel Pro Set Wireless utility and try uninstalling it (and another unfortunately has been the Altiris agent in the past).

Another thing that I wanted to mention is that we are looking at changing our SSO implimentation for Windows 7 specifically in a future release. This is to address some of hte timeout issues mentioned in here. But I'm not 100% sure on when that change is going to happen, it might possibly in our next major release that is scheduled to come out at the end of the year. I'm sorry if that doesn't help you much now.

But you can try those workarounds I suggested above. Another known thing to try is to change the PGP password filter driver to be at the top of the network provider list. This can be done under the network adapter configuration in Windows or else with a msi switch as part of the install when installing our product such as:

msiexec /i pgpdesktop.msi PGP_SET_HWORDER=1

I hope that this helps.

Thanks for the information Ben.  I received an answer on March 2nd from a Symantec employee.  He explained that the engineering team has a fix for this particular issue that is due to be released in late May. 

Yes, there are known issues getting resolved with our next update related to SSO on Windows 7.