Hello Team,
due to approach change, now client is not moving users to another new domain but splitting the existing domain itself.
can someone please suggest the way to split the users with tokens?
Hello Team,
due to approach change, now client is not moving users to another new domain but splitting the existing domain itself.
can someone please suggest the way to split the users with tokens?
There are a lot of possibilities here, so I'll restrict my answer to a general case.
Yes, when you export users and tokens from one deployment and import them into another deployment, token states are carried long, so users should be able to authenticate in the new deployment.
That said, User Group assignments, aliases and RADIUS profiles are not transferred, so if you have aliases, restricted Agents or RADIUS clients requiring user profiles, you will need to manually re-establish those in the new deployment. The Security Console help topic "Exporting and Importing Users and Tokens Between Deployments" is a treasure-trove of useful information to guide your planning.
what about authentication from old setup, can same user authenticate himself from old setup concurrently?
or the authentication will break in old setup, when users is started authenticated himself from new setup?
Again there are possibilities,
If you are asking whether the users be able to login to consoles of RSA of both environments, then the answer is yes.
But if you are considering devices that need to be authenticated to RSA with 2 factor authentication, then it has dependency of IP addresses/hostnames/sdconf.rec files etc.
It is important to also take note if the Agents know of the new information such as IP's/Hostnames of your new servers. Though the token and PIN associations are maintained during the export and import activity but that is not enough to say whether the authentications would work from end user or not against different deployments of AM.
-Sri
in the new environment agents are pointing to new F5 and checkpoint for new DMZ,other than that everything is same like software profile etc.
thats why the question:
" When performing the user/Token export and import into the new RSA cluster, will authentication of the same user & token be possible against both RSA clusters, or will the existing token no longer work and authentication has to be done via the new RSA cluster?"
if possible please help here.
The export/import is a copy operation, not a move, so it doesn't affect the user or token at the source system.
what about authentication:
" When performing the user/Token export and import into the new RSA cluster, will authentication of the same user & token be possible against both RSA clusters, or will the existing token no longer work and authentication has to be done via the new RSA cluster?"
I believe it will work on both source and target deployments.
The configurations need to be made on F5 and checkpoint to point to new target deployment. The other clients still pointing to source deployment shall work for these uses with the same tokens
-Sri
thanks Sri.
its entirely new DMZ setup so F5 and checkpoint build is also new.
new RSA setup will point to new F5 and CP, authentication will be valid still in both RSA setup?
i have imported 1 user from Source RSA to new RSA server and apart from token being imported i can see recent authentication activity as well.user is not admin them how come his recent activity updated in new RSA?
is it okay as part of user migration
someone please answer my above query.
recent activity on the new system or the old system?
i am seeing recent activity on new system
then it's working as designed. You would expect to see recent new-system activity on the new system.
i am seeing recent activity of the time when the USER/token was in old system.
"due to approach change, now client is..." This is getting more and more complicated. What, specifically, do you mean by "splitting the existing domain"? Are you staying with a single RSA Authentication Manager deployment? Are you moving users from one AD to another? Will you simply be creating an external Identity Source and using it for some of your existing SecurID users? Something else?
If you are having trouble determining the right way to proceed, you may want to talk to your RSA account manager about engaging RSA Professional Services to provide architecture and planning guidance for your project.
Disclaimer: I work for RSA Professional Services.
Currently AD is same in existing as well as target environment.
earlier client wanted to migrate users to different domain in existing RSA itself but due to some complexity, he is now continuing to use same domain in existing and target setup. but
target setup is built for different set of users which will be a subset of users from existing RSA setup.
so in this regard the question was for user authentication after export/import.
if we are exporting some users and tokens to new system and do not delete those users in current system.
importing those users and tokens to the new system, will it work, i mean users will authenticate with those token in new deployment?