- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Merging 2 seperate Authentication Managers into 1 primary/replica
We have 2 companies
We have 2 separate occurrences of authentication Manager
2 separate AD forests
We are going to merge the two companies into 1 company
In the mean time, we are setting up 2 way trusts in the AD
Can we not also merge the separate authentication managers in a primary / replica solution?
please let me know soon
Darrin
- Tags:
- Authenticator
- Authenticators
- Community Thread
- Discussion
- Forum Thread
- merger
- merger aquistions
- migrations
- RSA SecurID
- RSA SecurID Access
- SecurID
- Token
- Token Auth
- Token Authentication
- Token Authenticator
- Token Authenticators
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Darrin,
You can use trusted realm btw the 2 installations. See below :
https://community.rsa.com/docs/DOC-76711
Ange
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Suggestion> If you are going to merge 2 AD domains into a single one, if one of them is where users are currently picked up by 1 RSA deployment you could export users from the 2nd deployment and then import them onto the first deployment. If you are going to a 3rd separate domain from the first 2, can do 2 exports / imports.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One way to do it...If you want one primary:
Pick the RSA server you want to keep (target) and export users and tokens, and generate an encryption key.
On the RSA server you want to drop (source), and import encryption key, and run export users and tokens, and export.
On the target, make a new external identity source ldap connection (or modify the existing connection scope) and have that connect to AD for the same users that were in the export. The new users should be able to be listed on the Security Console but have nothing assigned yet and are not registered. Now run the import and point it to the external identity source where the users will be found, and if first name, last name, and default login matches, it will bring tokens and pins over and that should copy everyone over if the users are unique and no duplicates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To follow on with Edward Davis's suggestion, if you do decide to go with one primary, be sure to talk with your RSA sales rep or reseller about your plans ahead of time. Any available or assigned tokens you have on the two primaries will merge and will be available to your users but you will need to get a new license that covers all of the users in the merged primary.
Let's say each primary has a license for 1,000 users. Your merged primary will need to have a license with at least a 2,000 active user limit, larger if you plan to add more users.
Another option wou;d be to go through the Case Management Portal and open a case online. Please choose the Order Status, Maint Renewal, Trial or Sales Inquiries option.
Regards,
Erica
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is the merged environment going to maintain the original userids, or will some/all folks get new userids? Merging the two AM deployments will be easier if you can fix any userid clashes before merging. Admins on the source deployment will not automatically be admins on the new deployment, so you'll need to address that during/after the merge, as well as address any differences in Administrator Roles, Security Domains, etc..
Have you planned for reconfiguring the agents from the deprecated deployment to use the target deployment? At the least they will all need to be added as Agents in the target Security Console, then get a new sdconf.rec after the users are merged; additionally, each will need to have the node secret cleared at the Agent and regenerated automatically (by a successful authentication) or generated manually at the Primary and installed using the node secret tool.
I'd recommend practicing this on a test system first to make sure you have the steps well in hand. This is a fairly straightforward task but you don't want to be saying oops at 3am on some Sunday because half your people suddenly and unexpectedly can't authenticate.
If this starts to get more complicated than you hoped, talk to your RSA sales contact about engaging Professional Services to help you with the planning and execution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you all,
we are going with trusted realms
From review it appears to be the quickest and safest bet
Darrin
