HOW TO: Migrate Symantec Encryption Desktop and PGP Desktop Users from one Active Directory Domain to Another
Article ID: 181490
Updated On:
Products
Issue/Introduction
This article will go over the basic steps to migrate Symantec Encryption Desktop (PGP Desktop) and the user from one Active Directory Domain to another.
It is recommended to read through this entire document to ensure you have the process down and then test your particular scenario prior to migration in production.
Environment
PGP Encryption Server
Resolution
Migrating managed desktop users from one Active Directory domain to another requires some preparation for success.
This article shows an example of the process that should be followed. Symantec Enterprise Division recommends testing this on machines prior to the migration to anticipate any steps that may be unique to your environment. This process outlines a particular set of environment variables that were tested, but having different policies and keymodes should still be possible.
Environment
- Symantec Encryption Management Server (SEMS)
- Symantec Encryption Desktop (SED)
- Both the source and destination Active Directories are on the same Server platforms.
- The user's keymode is SCKM (other keymodes should be fine, but if CKM, or GKM keymodes are being used, be sure to backup the keys prior to making any of these changes).
- SSO (Single Sign-On) disabled via Consumer Policy
- Simple Bootguard authentication enabled via Consumer Policy
- Automatic encryption of boot disk enabled via Consumer Policy
- Directory Synchronization enabled on SEMS and LDAP enrollment is enabled.
- Both the source and destination LDAP Directories are configured in Directory Synchronization and confirmed working.
- Directory Synchronization is configured to check the AD servers for both AD domains (This will be good to keep in place during the migration process)
- Consumer Group Membership for the users being migrated is configured to check the appropriate AD security groups on both domain (This will likely require additional configuration to ensure the consumer grouping works for the new domain attributes).
Source Configuration
- Prior to the migration, the user "User1" is enrolled on the PGP client.
- User1 is a member of an AD domain called OldDomain.
- User1 belongs to an AD security group called OldADGroup.
- User1 belongs to a SEMS Consumer Policy called WDE-Users.
- User1's boot disk is encrypted.
- User1 has an SCKM format key.
- User1's keyring is in the default location (Documents\PGP) folder on the C drive (Keyring files are .pkr and .skr files and have been backed up).
- User1 does not have local admin rights on their machine.
Destination Configuration
- User1 is a member of the AD domain called NewDomain.
- User1 belongs to an AD security group called NewADGroup.
- The password for User1 on the NewDomain domain is different to the one for User1 on the source AD domain.
Migration Process
- User1 is added to the NewDomain domain via the Properties page of Computer within Windows. An administrator needs to do this because User1 has insufficient rights.
- After User1 has joined the NewDomain domain, Windows prompts the user to reboot.
- User1's bootguard passphrase is still valid.
- User1 logs in to Windows using the NewDomain\User1 account.
- Windows creates a new profile in the C:\Users\User1.NewDomain folder.
- Prior to enrollment, a local administrator had copied User1's keyring files from C:\Users\User1\Documents\PGP to C:\Users\User1.NewDomain\Documents\PGP
- User1 is prompted to enroll and enters their NewDomain credentials.
- The PGP Server does an LDAP lookup on the AD server hosting the NewDomain domain and finds User1.
- The NewDomain\User1 is in the AD security group NewDomaingroup which is linked to the WDE-users Consumer Policy, ie, no change of policy.
- In the key setup assistant User1 chooses the option that says they have existing keys and points to the folder C:\Users\User1.NewDomain\Documents\PGP
- The PGP Whole Disk Encryption Assistant states that the boot drive will be encrypted. User1 continues through the Assistant as normal by clicking the Next button.
- User1 chooses a WDE passphrase.
- The WDE Assistant starts to encrypt the drive but completes the task almost immediately. It does not re-encrypt the drive because the drive is already encrypted.
- The User Access list of WDE users shows two users: PGPTEST\User1 and NewDomain\User1.
- When User1 reboots they use their new WDE passphrase at bootguard.
- The User, Computer and Device records on Universal Server appear the same as when User1 was in the pgptest AD domain.
Things to check post migration:
*Once the above has completed, check the user account and ensure the PGP keys are the same and that the local keys remain the same.
*Reboot the system and ensure the user can login to the preboot using the newly enrolled credentials.
*Ensure the user is still able to access any encrypted content, such as PGPzip files, Virtual Disks, or File Share Encryption.
*Have the user send an email and ensure the email encryption is still working.
Troubleshooting:
If after migrating to the new AD domain the user cannot enroll, this is probably because of configuration errors with Directory Synchronization and/or the LDAP settings under Consumer Group Membership.
Check the Consumers\Directory Synchronization page to ensure both LDAP directories have been added.
Additional Information
Feedback
