Some PGP Desktop users not authenticating to PGP Universal Server

TECH176409
Last Updated April 09, 2012
Copy Article Title/URL
Feedback
Subscribe

Occasionally users who were previously enrolled attempt to update policy or make a connection to the PGP Universal Server, authentication fails and errors are displayed in PGP Universal Server client logs. The error lists the version of PGP Desktop being used for the connection attempt and the IP address from which it is making the attempt.

 

The Client logs may display the following entries:

failed authentication for internal PGP Desktop 10.0.2.13 user (null)from [10.1.1.133]

 

Possible resolutions:

1. Enable the disabled user.
2. Uninstall PGP from the machine where the user is no longer using PGP.
3. Re-enroll the user.
4. If the user's name changed in Active Directory, the user should be re-enrolled to accommodate this change.  The PGP Universal Server will not update this information automatically. 

5. Ensure the time is set to match the local timezone of the Symantec PGP Universal Server.

 

 

It may be beneficial to delete the user from PGP Universal Server and then re-enroll the user.  If this is done, please ensure users who have Whole Disk Encryption are re-enrolled immediately and make note of the recovery token in case they are needed later on.  Also make note of the machine ID associated to the Whole Disk Encrypted machine for reference.

 

NOTE: If the Symantec PGP Universal Server time deviates more than 2 hours from the local timezone set on the server, users will neither be able to update policy, nor enroll to the server.  Please ensure the time is accurate on the Symantec PGP Universal Server. 

For example, if the timezone is Pacific and local time is 10am, but the time on the Universal Server is set to 12:30pm, this will produce the problem.


Applies To

Possible causes for these errors:

1. User's is Disabled or non-existent in the Active Directory.
2. One computer used by multiple users and not all users are enrolled to PGP Universal Server.
3. The user's name changed and a re-enrollment has not taken place since this was done.
4. Base DN is too narrow and the user is not being found.
5. PGP Universal Server was restored to a point the user was not yet enrolled or the user was enrolled to a different server with the same hostname.  For example, the PGPStamp states ovid=keys.domain.com and this resolves to a new server.  Even though the user was enrolled to keys.domain, the actual enrollment cookie will be different for the PGP Desktop client.

Imported Document ID: TECH176409

Thanks for your feedback. Let us know if you have additional comments below. (requires login)

    © 1995-2019 Symantec Corporation