Video Screencast Help

"you do not have privilege to upload a Whole Disk Recovery Token to the server" error on a NIST-hardened computer

Created: 27 Dec 2012 | 3 comments


We've been trying to harden our Win7 computers with NIST USGCB guidelines.

One problem we've been running into is that if you're trying to register a user for WDE on a Win7 computer that has been hardened with the USGCB guidelines. When you get to the single sign on section of setting the user up, the first error you encounter is that when you give PGP the credentials, it gives you the error:

"Logon failure: The user has not been granted the requested logon type at this computer"

After some research, I discovered that this due to the setting in User Rights Assignment called "Access this computer from the network" which the NIST settings revoke all access except for Administrators.

but even after testing this out and adding the user I'm trying to register to the "Access this computer from the network" list, I get a second error after entering the single sign on credentials:

"you do not have privilege to upload a Whole Disk Recovery Token to the server"

This one I have not been able to figure out yet. If I attempt to register someone who is in the local Administrators group for the PC, registration goes fine or if I remove the hardening, then registration goes fine for everyone, including non-administrators.

So one of the NIST settings is preventing non-administrators from uploading the WDRT but I haven't had success yet in discovering which one.

What we're probably going to do when setting up users for WDE is that we will either temporarily make the user an Administrator, or set the user up on WDE *before* hardening the computer with the NIST USGCB guidelines, but I'd still like to know what setting is blocking the the registration from working correctly. I searched the forums and google and haven't found anyone with a similar situation.

Any ideas?

Thanks in advance.

Comments 3 CommentsJump to latest comment

PGP_Ben's picture

I found a KB article that may apply here? We read the Machine GUID in the registry and also try to upload the WDRT. If we already see a WDRT on the server of machine with that same machine GUID (Or possibly even just a problem reading that registry key?) then that may be where the error is coming from.

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

NETimMenke's picture

That may at least point me in the right direction.  The error only seems to crop up on computers that have been hardened with NIST guidelines and if the user doing the enrollment is a non-administrator.  So if PGP is attempting to read a registry key remotely,  I believe the hardening restricts remote access to the registry.

however, PGP_Ben, the KB article you've linked to sends me to an invalid page.  could you attempt to link again?

I assume the article talks about what specific registry key is being read? 

PGP_Ben's picture

Sorry, the KB aritlce is showing as internal only for some reason. Here is the information (not sensitive) so I will have to fix the KB when I get back in the office:


This usually results in a uniquie identifier being found on the server for the hardware in questions as a result of being encrypted once before and not decrypted in the normal way. The fix is to change the registry in the HKLM>Software>PGP  Corporation> PGP> MachineGuid


Changing one character in the string to another hexadecimal number (0-f) and then Re-enrolling fixes the issue. Re-enrolling is done by making sure pgptray.exe is not running in the processes in task manager and then removing the PGP  Corporation folder from the user's application data directory.  Then restarting the pgptray.exe service found in All Programs>startup will begin the enrollment process again.


A few of my notes from Enterprise deployment scenarios that I have seen is that we do require remote registry in order to enable SSO users to enroll and encrypt the disk. If this is disabled that will not work correctly.

I think in some cases we found that adding a user manually through PGPWDE commands and then encyrpting the disk instead is a way of getting around that.


pgpwde --add-user --disk 0 --user "username" --domain "DOMAIN here" --sso -p "passphrase here"


pgpwde --encrypt --disk 0 -p "passphrase here"

That might work, another option is the --secure command which does this all in one command:

pgpwde --secure --disk 0 --user "username" --domain "DOMAIN here" --sso -p "passphrase here"

I would try both of those options to see if that helps.

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