AnsweredAssumed Answered

Keeping a Dev and Prod Authentication Manager system in sync.

Question asked by Michael Folsom on May 1, 2019
Latest reply on May 6, 2019 by Jay Guillette

Like • Show 0 Likes0
Comment • 7

Hi:

I'm curious about process and a bit new to RSA Authentication Manger. I have a Prod and Dev setup running 8.3. Both systems consist of a Manager and a Replica. I am starting to try and automate the addition and removal of Agents and Users from the system and really need my Dev to be somewhat like Prod. To do this I would like to periodically do a backup of Prod and put it on Dev which is easy to do. My experience so far has been mixed. While it is possible to do this I have discovered that I loose my Replica on Dev in the process.

Is there a way around this so that I can have a real test/Dev system that is somewhat in sync with Prod. I don't what to have to "re-initalize" my Replica every time Dev gets updated.

Hopefully this makes some sense -

Thanks in advance -

M-

Jay Guillette

May 2, 2019 1:41 PM

Correct Answer

Unless you created your Prod primary as a VMWare VM first, then cloned it and at the VM level and put it on a Dev ESX server, then your Prod and Dev Primaries are not the same, even if they had the same name and IP address. When you deploy a primary, you create a unique Private / Public Key pair, and your replicas have unique GUIDs in the internal database. That is why, when you backup the Prod Database and then restore to the Dev Primary, you break any existing Dev replicas and need to redeploy them.

Therefore keeping your Prod and Dev systems in synch is not just a matter of backup and restore of the database. So you kind of have to decide how in synch you want them to be, because it might involve something like performing the same agent creations and user additions either manually or in bulk with AMBA. Or maybe you just want to use Dev to test patching before you patch Prod, so they are not completely in synch with all users and agents but are in lock step sycnh . Or maybe you want everything in VMWare, your Primary, Replicas, and your LDAP external Identity Sources, and you 'big' or important protected applications or agents all periodically cloned over to Dev.

Or after considering the can of worms I just opened for you, you decide re-deploying a replica or two is not so bad after all.

See the reply in context

No one else had this question

Outcomes

Jay Guillette

May 2, 2019 1:41 PM

Or after considering the can of worms I just opened for you, you decide re-deploying a replica or two is not so bad after all.

Actions

Michael Folsom @ Jay Guillette on May 2, 2019 1:39 PM

Jay:

Thanks for the quick responss, background and info!

I think your final line is the answer - I just need to "re-deploy" the replica.

Now my next question is how do I get my detached replica in a state where I can re-attach it. I can ssh to it but looking at the instructions in "RSA® Authentication Manager 8.3 Setup and Configuration Guide" it appears I need to connect to "Quick Setup" which doesn't appear to be available on the replica - actually neither the OC or SC consoles are available so perhaps none of the replica's web services are up and running.

Thanks again -

Mike

Actions

Jay Guillette

@ Michael Folsom on May 2, 2019 1:45 PM

You have to deploy a new replica, so if you have a virtual machine, you simply discard the current replica and get VM to deploy a new .iso (or Hyper-V or AWS .ami or Azure Cloud whatever they use) for AM 8.3 in your case.

If you have a hardware appliance then you need to "factory reset" that replica appliance back to base AM 8.3, by following this KB

https://community.rsa.com/docs/DOC-62265

Actions

Michael Folsom @ Jay Guillette on May 6, 2019 2:07 PM

Jay:

Thanks for your work on this. I have looked at the DOC you pointed to and read a couple of others and it appears that while there is a "factory reset" option for a hardware based replicas there isn't one for a "vm". Am I correct on this?

I know I can just replace the vm but sometimes that is easier said than done ---;-{

Be well,

Mike

Actions

Jay Guillette

@ Michael Folsom on May 6, 2019 6:37 PM

I don't think anyone tried to factory reset a VM, though it might work.

It seems that VM people and AM people do not eat lunch together, so the communication link between the two groups can be a little too formalized which can make it harder to get a new VM .ova deployed (you're not the only customer I hear this from). That's a layer 8 problem on the OSI model. And as the OSI model also teaches: problems that arise at a layer should be fixed at the same layer.

Actions

Edward Davis

@ Michael Folsom on May 2, 2019 1:50 PM

If you restored the primary instance with a backup that came from a different deployment, then the restore operation automatically deletes each replica instance from the current deployment. A backup that is restored from the current primary instance in the current deployment retains each replica instance.

Those deleted Replicas will not work with that Primary again, they need to be re-deployed from scratch, using the highest base version that matches the Primary, and set up as new Replicas. Then afterward can be patched up to the minor patch level.

Base versions are: 8.1.0.0.0, *8.1.1.0.0 hyper-v only*, 8.2.0.0.0, 8.2.1.0.0, 8.3.0.0.0, 8.4.0.0.0

Actions

Michael Folsom @ Edward Davis on May 6, 2019 2:10 PM

Ed:

Thanks for the info & help -

When I started this we all just agreed that it was time for the Dev environment to match Prod. I'm now seeing that if Dev has a replica this is easier said than done ---

Mike

Actions

7 Replies

Jay Guillette May 2, 2019 1:41 PM
Unmark Correct
Correct Answer
Unless you created your Prod primary as a VMWare VM first, then cloned it and at the VM level and put it on a Dev ESX server, then your Prod and Dev Primaries are not the same, even if they had the same name and IP address. When you deploy a primary, you create a unique Private / Public Key pair, and your replicas have unique GUIDs in the internal database. That is why, when you backup the Prod Database and then restore to the Dev Primary, you break any existing Dev replicas and need to redeploy them.

Therefore keeping your Prod and Dev systems in synch is not just a matter of backup and restore of the database. So you kind of have to decide how in synch you want them to be, because it might involve something like performing the same agent creations and user additions either manually or in bulk with AMBA. Or maybe you just want to use Dev to test patching before you patch Prod, so they are not completely in synch with all users and agents but are in lock step sycnh . Or maybe you want everything in VMWare, your Primary, Replicas, and your LDAP external Identity Sources, and you 'big' or important protected applications or agents all periodically cloned over to Dev.

Or after considering the can of worms I just opened for you, you decide re-deploying a replica or two is not so bad after all.
Like • Show 1 Like1
Actions
- Michael Folsom @ Jay Guillette on May 2, 2019 1:39 PM
  Mark Correct
  Correct Answer
  Jay:
  
  Thanks for the quick responss, background and info!
  
  I think your final line is the answer - I just need to "re-deploy" the replica.
  
  Now my next question is how do I get my detached replica in a state where I can re-attach it. I can ssh to it but looking at the instructions in "RSA® Authentication Manager 8.3 Setup and Configuration Guide" it appears I need to connect to "Quick Setup" which doesn't appear to be available on the replica - actually neither the OC or SC consoles are available so perhaps none of the replica's web services are up and running.
  
  Thanks again -
  
  Mike
  Like • Show 0 Likes0
  Actions
  - Jay Guillette @ Michael Folsom on May 2, 2019 1:45 PM
    Mark Correct
    Correct Answer
    You have to deploy a new replica, so if you have a virtual machine, you simply discard the current replica and get VM to deploy a new .iso (or Hyper-V or AWS .ami or Azure Cloud whatever they use) for AM 8.3 in your case.
    If you have a hardware appliance then you need to "factory reset" that replica appliance back to base AM 8.3, by following this KB
    https://community.rsa.com/docs/DOC-62265
    Like • Show 1 Like1
    Actions
    - Michael Folsom @ Jay Guillette on May 6, 2019 2:07 PM
      Mark Correct
      Correct Answer
      Jay:
      
      Thanks for your work on this. I have looked at the DOC you pointed to and read a couple of others and it appears that while there is a "factory reset" option for a hardware based replicas there isn't one for a "vm". Am I correct on this?
      
      I know I can just replace the vm but sometimes that is easier said than done ---;-{
      
      Be well,
      
      Mike
      Like • Show 0 Likes0
      Actions
      - Jay Guillette @ Michael Folsom on May 6, 2019 6:37 PM
        Mark Correct
        Correct Answer
        I don't think anyone tried to factory reset a VM, though it might work.
        It seems that VM people and AM people do not eat lunch together, so the communication link between the two groups can be a little too formalized which can make it harder to get a new VM .ova deployed (you're not the only customer I hear this from). That's a layer 8 problem on the OSI model. And as the OSI model also teaches: problems that arise at a layer should be fixed at the same layer.
        Like • Show 0 Likes0
        Actions
  - Edward Davis @ Michael Folsom on May 2, 2019 1:50 PM
    Mark Correct
    Correct Answer
    If you restored the primary instance with a backup that came from a different deployment, then the restore operation automatically deletes each replica instance from the current deployment. A backup that is restored from the current primary instance in the current deployment retains each replica instance.
    
    Those deleted Replicas will not work with that Primary again, they need to be re-deployed from scratch, using the highest base version that matches the Primary, and set up as new Replicas. Then afterward can be patched up to the minor patch level.
    Base versions are: 8.1.0.0.0, *8.1.1.0.0 hyper-v only*, 8.2.0.0.0, 8.2.1.0.0, 8.3.0.0.0, 8.4.0.0.0
    Like • Show 1 Like1
    Actions
    - Michael Folsom @ Edward Davis on May 6, 2019 2:10 PM
      Mark Correct
      Correct Answer
      Ed:
      
      Thanks for the info & help -
      
      When I started this we all just agreed that it was time for the Dev environment to match Prod. I'm now seeing that if Dev has a replica this is easier said than done ---
      
      Mike
      Like • Show 0 Likes0
      Actions

Keeping a Dev and Prod Authentication Manager system in sync.

Outcomes

Related Content

Recommended Content