Hello Team,
one of our client is using xyz.com domain currently and want to migrate to abc.com domain.
can someone please list down the changes we need to perform while doing this in RSA securID setup?
Thanks,
Sumit
Hello Team,
one of our client is using xyz.com domain currently and want to migrate to abc.com domain.
can someone please list down the changes we need to perform while doing this in RSA securID setup?
Thanks,
Sumit
There are a lot of things to consider, but I'll try to summarize.
From a Domain perspective there's basically the what and when, what is the new name of everything, and when will that be reflected in DNS and/or AD. A cut over might be easier to plan and implement but harder to make work when you realize not everything was changed. So maybe a migration where both domains are maintained in DNS/AD while individual objects have their names changed.
From an Authentication Manager perspective, there are three main things I can think of;
1. The AM servers may need their name changed - do this in the Operations console, not in Linux!
2. Agents may also need their names changed. Windows agents that auto-register might not need anything done in the AM Security Console but a lot of things done on the agents, and in DHCP and DNS. RADIUS clients typically do not need to resolve their names correctly though you could get a warning about it in the Security Console.
3. UserIDs - if you use an LDAP external Identity Source, do you also use UPN names or SamAccountNames? I'd think SamAccountNames would remain the same even if the Domain name changes, but if you use UPN you may have to monitor your LDAP Identity Sources. If it is just the Domain that changes, later versions of AM (> 8.2 base) are very good at resolving UserIDs even when something changes, such as Last Name, or DN or ou, but if several attributes change at the same time then AM can lose the pointer to the User. If users cannot be resolved, I would NOT run a clean-up job as that would unassign all tokens for these users and clear all PINs for those tokens.
Review this KB for reference https://community.rsa.com/docs/DOC-45370
It's called 000033238 - How to create an external LDAP identity source in RSA Authentication Manager 8.1 SP1 or later
Thanks for the prompt reply Jay.
there is one more scenario; in case appliance location is changing?
what changes will take place w.r.t AM?
The Appliance Operations console - Administration - Network - Appliance Network Settings, is where you can change either the Appliance FQDN or its IP address, or both.
network settings need to be changed in replica as well? i.e. new primary ip and new ipv4 settings for replica appliance.
also will the agents also need to register again as now both primary and replica have new ipv4 settings?
Please review Online Help Topic, Update the Primary Instance Hostname and IP Address on a Replica Instance:
https://community.rsa.com/docs/DOC-77095
Find a full detail of what is involved when changing the Primary Instance IPv4 Network Setting in Online Help:
https://community.rsa.com/docs/DOC-76766
For changing the replica instance IPv4 Network Settings, find relevant contents in Online Help:
https://community.rsa.com/docs/DOC-76930
For your agents, you need to generate a new configuration file to communicate with the new IP addresses.
Sumit,
As Moses points out, there is a lot of help, but I would simply say change the name and/or IP of the AM primary and replicas in their respective Operations console, one at a time, and the AM server will notify the other servers, so that you can avoid having to re-deploy or re-attach replicas, at most you would have to re-synchronize them.
Thanks much Jay, Moses. it really helped to gather points to build the migration approach.
now the approach is client has decided to just change the name of the domain i.e. from xyz.com to xyz_1.com.
so as per your first reply:
1- only AM names i.e.only FQDN will be changed no ip address change as appliance are not moving. what about changes on replica as FQDN is required only on Primary instance.?
2- agents also need to change ----> can you please elaborate more on this because when we generate sdconf.rec file it contains only ip addresses of the primary and replica servers. i read it in one KB on community:
https://community.rsa.com/docs/DOC-47017
3- do i need to configure the AD again as the domain name is changing?
if possible can you please provide screenshots of the changes required as you provided previously.
Thanks,
Sumit
Hello jay,
will it disconnect all users including me whoever is connected if i change the FQDN of RSA?
There are a lot of things to consider, but I'll try to summarize.
From a Domain perspective there's basically the what and when, what is the new name of everything, and when will that be reflected in DNS and/or AD. A cut over might be easier to plan and implement but harder to make work when you realize not everything was changed. So maybe a migration where both domains are maintained in DNS/AD while individual objects have their names changed.
From an Authentication Manager perspective, there are three main things I can think of;
1. The AM servers may need their name changed - do this in the Operations console, not in Linux!
2. Agents may also need their names changed. Windows agents that auto-register might not need anything done in the AM Security Console but a lot of things done on the agents, and in DHCP and DNS. RADIUS clients typically do not need to resolve their names correctly though you could get a warning about it in the Security Console.
3. UserIDs - if you use an LDAP external Identity Source, do you also use UPN names or SamAccountNames? I'd think SamAccountNames would remain the same even if the Domain name changes, but if you use UPN you may have to monitor your LDAP Identity Sources. If it is just the Domain that changes, later versions of AM (> 8.2 base) are very good at resolving UserIDs even when something changes, such as Last Name, or DN or ou, but if several attributes change at the same time then AM can lose the pointer to the User. If users cannot be resolved, I would NOT run a clean-up job as that would unassign all tokens for these users and clear all PINs for those tokens.
Review this KB for reference https://community.rsa.com/docs/DOC-45370
It's called 000033238 - How to create an external LDAP identity source in RSA Authentication Manager 8.1 SP1 or later