Migrating from one Domain to a New Domain with Symantec Endpoint Encryption Management Server (From Old Domain to a new Domain)
Article ID: 266993
Updated On:
Products
Issue/Introduction
This article will cover the items you will need to consider to move from one domain to another.
For example, your organization is changing from one Active Directory Domain (original.example.com) to a new Active Directory domain (new.example.net).
*All the SEE Clients are configured to use HTTPS
*All clients are configured to use "Windows Authentication"
*The SEE Management Server Database will be moved from one location to another.
*The SEE Management Server will get a new TLS Certificate, and the signer will be completely new (Root Certificate Authority will be new).
*A Two-way Trust is not necessarily available from the original.example.com to the new.example.net.com and vice versa (completely new domain)
Resolution
Migrating from one domain to a completely new domain is no small task. There are some items for you to consider. This article has several sections to review:
Table of Contents
Section 1 of 3: Prerequisites - Backup the current Configuration
Before doing anything, it is a good idea to take backups of the entire environment. Check out the following article for information on what to backup:
Section 2 of 3: Considerations Before Migrating to a new Domain
Item 1: Will the Windows Server be changed? If so, which operating system will it be on?
If you are running on an old version of Windows Server, now is a good time to consider finding a new operating system that will be more optimal.
For example, if you are on Windows Server 2012, this will be EOL by October 2023. Check out the System Requirements to find an optimal fit for the OS.
If you decide to install on a new server, then you will need to have the backups mentioned in the KB above ready and available for use once on the new OS.
Item 2: Which DNS host/URL will be used after the domain migration?
If the Windows Server will be completely new, then you will need to take your backups and a new installation must be done.
The DNS values will be very important for the existing SEE Clients to be able to connect. For example, when the SEE Management Server is installed, you will specify the hostname for the server, such as "seems.original.example.com". When the SEE Clients are created, the URL will be built in. If your DNS can resolve the old host, then you are good, but if not, you will likely be looking at creating a new SEE Client. This is likely a good option, and a necessary option considering other items we will further discuss.
Item 3: Will the "Windows Authentication" method fail when on the new domain for the SEE Clients?
When the SEE Client is built, previous versions before SEE 11.4 required a username and password for authentication to the SEE Management Server. This username and password is inbuilt to the client, and is used automatically to connect to the SEE Management Server for policy updates or check-ins. This account is a regular, read-only account that would have the capability to "authenticate" to the domain URL used. When the SEE client connects to the SEE Management Server, the credentials are passed that were built in, and this authenticates the client.
If you are moving to a new domain, such as "new.example.net", it is possible the account used for this will no longer be able to authenticate as the username/password would most likely be different. In this case, a new SEE Client will need to be created once on the new domain as well.
Because a new SEE Client will need to be created, new credentials will need to be entered. Rather than rely solely on "Windows Authentication", we recommend, instead, to use our new authentication mechanism, which is called "OAuth". OAuth uses tokens to authenticate from the client-to-server, and these tokens are completely unique to the server from which the client is built. OAuth offers much more flexibility for the authentication and is fairly easy to configure. For more information on OAuth, see the following article:
240321 - OAuth Communications with Symantec Endpoint Encryption 11.4 and above
When the new SEE Client is built with OAuth, you can then disable the old "Windows Authentication" account and OAuth will be used going forward, making your future deployments much more simple.
Note: There is a "Change Web Access" feature available, but reviewing all of these items, you will likely find it will be better to create a new SEE Client that has the new information for simplicity.
Item 4: Will the TLS Certificates be created by a new internal Certificate Authority as part of the new.example.net domain?
When the SEE Client is configured to use HTTPS, a TLS Certificate is used. To be able to use a TLS cert, a proper FQDN should be used, and it is also recommended to use a Subject Alternative Name or SAN.
If you are changing domains, the hostname may change and subsequently, the FQDN for the server may change. As an example, the TLS cert may be generated for "seems.original.example.com", and the new domain may then be "seems.new.example.net". Therefore, it may be necessary to obtain a new TLS certificate.
A new TLS Certificate may be needed as it may be signed by a completely new Root Certificate Authority for the organization. If the new Root Certificate Authority is different, a new SEE Client must be generated and deployed.
Item 5: Will the current "Server Roles" be changing as the original domain users may no longer be valid in the new domain.
One of the very special things about the SEE Management Server is that it has very easy and seamless integration into the Active Directory. This is done simply by installing the SEE Management Server on the Windows Server that is joined to the domain. The user context for this installation establishes this context, and therefore, no further steps are needed to get this integration.
If you are going to be moving to a completely new domain, then this may be easily done simply by installing the SEE Management Server into the new domain. The new integration should then be seamless as before, but this is all within the confines of using the same database. So while not much is needed, the next item will require the same database to be used.
Because this integration is seamless after the installation into the new domain, the old server roles may no longer be valid. So in preparation for moving the domain, make note of all the users and groups who would need to be migrated. Once they are, you will simply add the new users and new groups to Server Roles, and you should then be good to go from this perspective.
The exclusion to this would be if there was a true "two-way" trust, such that all the information from the old domain is still available with the server being joined. This should all be automatic, and no special configuration is required.
Item 6: Database
As mentioned at the beginning of this article, backups of several items should be done. One such backup is the Database. Once you backup the database, it can be used to restore to a completely new server. You will need to put the database backup into the proper location/instance and when you do the new installation of the SEE Management Server, you will simply point to the new Database.
Item 7: Which Policy Type are you using? Should you consider changing?
One major benefit to using the SEE Management Server is the ease of use. One such method is the use of "SEE Native Policies". This means that all the policies are stored on the SEE Management Server and are easily reviewed and accessible.
If you are not sure if you are using "SEE Native Policies", simply open the SEEMS Configuration Manager, click on the Active Directory tab. If there is a domain listed here, you are not using the SEE Native Policy and you really should consider moving to this paradigm. There are several advantages to using SEE Native over the "Active Directory" policies, and are discussed in detail in the following article:
So if you are migrating to a new domain, now is a good time to consider switching to SEE Native Policies and stop using GPO policies, which are more complex to manage.
Section 3 of 4: Upgrading the SEE Clients with the new SEE Client from the New Domain
After you have installed the SEE Management Server to the new Windows server part of the new domain, you should be able to then start to assign the new Certificate to the SEE Management Server, then configured the policy to accept OAuth, and ensured the network connectivity is good. Once you've done, this you are ready to create your new client and then deploy that over the top of your current clients.
Deployment is a special step, and if you are going to be upgrading to a new version, you can simply install right over the top.
We recommend using the latest version of the SEE Client for best deployment performance. At the time of this writing, SEE 12 s the latest release. For more information on how this should work, we advise you to consult with Symantec Encryption Support for further guidance, which leads us to Section 4 of 4.
If you are not on Symantec Endpoint Encryption 12 or above, we recommend first migrating your database from the original.example.com to new.example.net domain using the same version of SEE. For example, if you are on SEE 11.4 MP2, then restore your existing backup to the new domain on SEE 11.4 MP2. Once you have migrated and everything is successful, then look into upgrading.
See the following article for information on the SEE 12 upgrade:
205088 - What's New with Symantec Endpoint Encryption version 12 (and 11.4 and 11.3.1)
276501 - Groups, Policies, and Client Creation with Symantec Endpoint Encryption version 12
Section 4 of 4: Specific needs for your Environment
It may be possible you have a slightly different environment, and for these, the above may answer your questions. Testing is always a great plan, but if you have any specific questions, feel free to reach out to Symantec Encryption Support for further guidance and we can collaborate with any specific needs you may have.
Additional Information
Scenario 1: Moving SEE Client from Old SEE Management Server to New SEE Management Server
163292 - Migrating from one SEE Management Server to another (Completely new SEE Database)
Scenario 2: (Moving from PGP client/sever to SEE client/server)
227509 - Migrating from Symantec Encryption Desktop to Symantec Endpoint Encryption (Drive Encryption components)
Scenario 3: Moving SEE Clients from the same database to another SEE Management Server with the same Database
154122 - How to Migrate Symantec Endpoint Encryption Management Console and all the clients from one Server to another Server, without moving the existing SQL Server
Scenario 4: Moving same SEE database from one DB instance to another
152340 - How to move the SEE-MS SQL database from one server/instance to another
Scenario 5: Update which hostname the SEE Clients use for communications (Keeping same database)
249333 - Changing Web Access for SEE Clients on Symantec Encryption Management Server
Scenario 6: Moving the SEE Database from one domain (original.example.com) to a completely new domain (new.example.net)
266993 - Migrating from one Domain to a New Domain with Symantec Endpoint Encryption Management Server (From Old Domain to a new Domain)
Feedback
