Video Screencast Help

WDRT and Disk Admin Passphrase doesnt unlock WDE clients on 10.3 MP1

Created: 03 Apr 2013 | 8 comments
bgee's picture

hi there,

userguide describes the use of disk-admin pw and WDRT as following :

"Lock passphrase user accountsafter 3 failed login attempts: Type in how many
failed login attempts can occur before the encrypted disk is locked. You cannot
lock out a user before three failed attempts.
If the disk is locked, all passphrase users lose access. All accounts on the disk are
locked. Users cannot log in again without using a WDRT or other token. An
administrator with a PGP Whole Disk Encryption administrator key can also
unlock the account. If one user logs in with a WDRT or other token, the disk
unlocks and all passphrase users can log in again.
Without a WDRT or other token,
the disk is permanently locked.

In our case we have domain clients and non-domain clients with managed Universal Server , Universal is on 3.3.0MP1 , and the clients on 10.3_MP1 , all Windows7 .

We manually entered 3 times the wrong password, the Notebook locks everything and we can authenticate when using DiskAdminPW or WDRT of the user, both are working , but unfortunately as described in userguide the PreBoot doesnt get "unlocked". the next time boot still shows "locked" and so the user cant login properly.

sounds like a bug , cause i dont know any setting in consumter policy to prevent "unlocking" preboot upon using WDRT or DiskAdminPW .

I remember old case where PGP Desktop didnt sync the changed user's password with the SSO logon of preboot, but this was fixed.

Another idea would be to switch from SSO back to normal preboot-user  + additional domain user logon but we want to use SSO for ease of use.


Operating Systems:

Comments 8 CommentsJump to latest comment

bgee's picture

To give further information :

The particular user has 2 clients , one is desktop client wihtout PGP/WDE

and one client with WDE and crypted HDD , the password change occured upon domain policy on the desktop computer yesterday, he changed his password on the desktop computer and started his WDE crypted notebook later the day and then the following he made :

while the password on the domain client was changed successful he started later the day his notebook and unfortunately entered his "new" password on the pre-boot whcih is as we know "wrong" (but he didnt know or forget) cause still the old password is there cause no network connection on pre-boot as we all know by ourselves.

while he entered 3times the wrong password the client locked and he was only able to authenticate with WDRT or with our diskadmin_passphrase. The windows started normaly, upon the domain logon he was able to use his previously (on desktop computer) changed domain password.

And now we just wonder "why" the notebook with WDE doesnt sync this password or "unlocks" the preboot which was still locked. cause when you now reboot then the client is still locked.

The only thing which helped here was to re-change the password in the WDE client and then it was succesful sync'ed <- but this cant be the workflow and should be tracked as BUG cause you cant expect from users to change twice their password.

let's discuss.. i dont think we did something wrong, a normal usual workflow and this should work smooth without hassle to re-change password


Alex_CST's picture

That doesn't sound like usual behaviour, the user should only have to change their password once when they get locked out.  I'm sure a Symantec employee would be able to verify if this is intended behaviour (doubtful) or a bug (probable)

As you know the AD password sync would occur upon the encrypted machines booting into windows and PGP Desktop starting itll then get the new password, but if i understand your point, when you restart AFTER unlocking with WDRT AND the policy has been updated, it still says its locked correct?

Please mark posts as solutions if they solve your problem!

bgee's picture


nevertheless with or without updating policy the "locked" screen still comes. Things getting funnier.. my collegue as i told changed again his AD_password and then he still sees upon next boot the "locked screen" BUT he's able to logon "once".. then if rebooting again it's static locked again ?

funny? it aint! ;-)

Alex_CST's picture

Curiouser and curiouser....

On the universal server is it correctly identifying the login failures on that device?

Please mark posts as solutions if they solve your problem!

PGP_Ben's picture

I have heard similar reports from other customers. I believe there is a bug logged on this issue. I would be curious to see if you see anything informative in the desktop client logs related to WDRT failures, etc. Usually it shows up as something like "corrupt file" or "corrupt prefs" or something along those lines.

If/when you consider your issue resolved, please click Mark As Solution on the most helpful response.

PGP_Ben's picture

oh sorry, an useful workaround you could try in the field while we are working on a solution:

1) drop to a command prompt in windows

2) c:\program files (x86) or c:\program files\pgp corporation\pgp desktop\pgpwde.exe --unlock --disk 0 (or disk 1 if it's attached externally of course) --wdrt "WDRT HERE" or --ap "admin passphrase here"

3) Then verify that the user is unlocked indeed here:

pgpwde.exe --list-users --disk 0 --ap "admin passphrase" or --wdrt "wdrt here"

4) Also, a status command will tell if you the user authentication on the disk is locked or not

pgpwde.exe --status --disk 0 --ap "admin passphrase" or --wdrt "wdrt here"

If/when you consider your issue resolved, please click Mark As Solution on the most helpful response.

bgee's picture

Hi Ben,

this workaround works here on our environment only for non-domain clients , i tested twice to lock manually my notebook which is non-domain joined but same PGP desktop with same policies as my collegues with domain-clients with pgp desktop installed.

The funny behaviour is : if doing list-users or status on my non-domain client , it doesnt show that it's currently locked, if you reboot it's locked still , only if you finally use --unlock it's "unlocked" and the lock screen on bootguard disappears and you can login normally again. in all cases i used CLI commands with the AP not the WDRT... i will test with WDRT on domain-clients again to see if this changes something...

i tested yesterday on my non-domain client without your commands and sometimes it unlocked it magically without any user interaction because yesterday it suddenly was unlocked without any corporate network access , i saw that there was no network access cause the WDRT wasnt changed.


on domain clients i see on the CLI command status/list-users that it's really locked , it says "lockout triggered" and the users has A: S L <- means locked.. on my non-domain client only A: S was , never L , but locked anyways...

strange aint?

for us at the moment until an update is released users who are forced regarding 90days password change they have to use the WDRT as workaround.

if i get better results with WDRT instead of use of AP i will let you know on domain-clients.

what i dont understand is : what makes here difference regarding domain/non-domain clients, thats the only difference for the moment, all clients use same PGP Desktop MSI , win7-64bit and same group/policy...

i will investigate client log on domain-client aswell.. to see differences to the non-domain client.

Do you have a  BUG ID where i can reference to ?


PGP_Ben's picture

here is one issue documented (which is currently being worked)

If/when you consider your issue resolved, please click Mark As Solution on the most helpful response.