Hello Team,
i have some questions on full backup:
what does Backup File Contains?
does it contain profile, users, group, domain,policies?
Also if we are using external identity source and taking full backup, will everything be backed up?
if i take backup of authentication manager which is hosted on hardware appliance and importing that backup on the authentication manager which is hosted on virtual appliance, will it work?
A few important points - the backup dump file contains;
1. agents, RADIUS clients, tokens, User PINs, On-Demand and RBA assignments, RADIUS profiles, groups, policies, Admin Roles, Security Domains
2. Users: from the Internal database and the LDAP external Identity Source configurations that allow AM to find Users in AD or other LDAP Identity Source, including the LDAP Admin account and password
3. The AM Primary configuration FQDN and IP address(es) as well as the server.cer internal certificate (and its copy in the sdconf.rec file) used by TCP and ReST agents. UDP based agents do not use certificates - they have their own encryption methods
The backup dump file kind of contains;
1. the replicas - however this only works when this backup dump is restored to the same primary it was taken on. You can restore a backup dump from one primary (e.g. Production) to another Primary (e.g. Dev, provided they run the same version of AM) but the replicas will not work, and you would overwrite any configuration of TCP or ReST agents. Note: the same Primary means the exact same primary and not a primary that looks like the original, e.g. same name and FQDN. There are benefits to running primaries on VMware because you can clone a VM. You can also snapshot a VM, which is a great help on a version update that does not allow roll-back, especially if an update fails.
The backup dump file does not contain;
1. the key stores that contain replacement console and web tier certificates
Hi Jay Guillette,
Sorry for the interruption in between, Caa help elaborate "key stores that contain replacement console", what this related to?
thanks
M.Tech Products Pte Ltd [Rajesh Gogineni]
When you deploy a Primary or Replica AM server, RSA generates a Key-pair and the public key is presented every time you connect to the Security or Operations Console. Since the public key used in the Certificate, and really the Certificate is signed by RSA, (self-signed) it is not trusted by default by browsers, therefore you get the Certificate warnings and you have to click OK to continue. The site even gets listed as un-secure.
If for Policy or other reasons you want to avoid this Cert warning, you can replace the RSA self-signed console certificate with one signed either by a Public CA like Go-Daddy or Verisign, or by your own company's internal CA, e.g. Microsoft CA Server. You can do this in the Operations Console.
Console certificate management is not exactly part of Authentication Manager, it has more to do with the identity of the primary or replica, therefore the key-store that holds either the RSA self-signed Certificate or any replacement console Certificate is not backed up by the Operations Console backup procedure. This is not really problem, in fact it could be a problem if the certificates were included in the backup and you restored that backup on a different server, you could mess up that server's identity Certificate if you overwrote it.
So not backing up the key-store with console certificates is not a problem in the normal course of events in Authentication Manager because console certificates are more fundamental to a Server than the AM database, the console certificates would already be in any AM server that you were trying to restore a database backup to.
A few important points - the backup dump file contains;
1. agents, RADIUS clients, tokens, User PINs, On-Demand and RBA assignments, RADIUS profiles, groups, policies, Admin Roles, Security Domains
2. Users: from the Internal database and the LDAP external Identity Source configurations that allow AM to find Users in AD or other LDAP Identity Source, including the LDAP Admin account and password
3. The AM Primary configuration FQDN and IP address(es) as well as the server.cer internal certificate (and its copy in the sdconf.rec file) used by TCP and ReST agents. UDP based agents do not use certificates - they have their own encryption methods
The backup dump file kind of contains;
1. the replicas - however this only works when this backup dump is restored to the same primary it was taken on. You can restore a backup dump from one primary (e.g. Production) to another Primary (e.g. Dev, provided they run the same version of AM) but the replicas will not work, and you would overwrite any configuration of TCP or ReST agents. Note: the same Primary means the exact same primary and not a primary that looks like the original, e.g. same name and FQDN. There are benefits to running primaries on VMware because you can clone a VM. You can also snapshot a VM, which is a great help on a version update that does not allow roll-back, especially if an update fails.
The backup dump file does not contain;
1. the key stores that contain replacement console and web tier certificates