You can export an existing Access Gateway configuration as well as its dependent policies, and then import this configuration to a new machine. This feature is especially useful for deployments that set up configurations in a staging environment, test and validate the configuration, then want to deploy the configuration on new hardware that exists in the production environment.
IMPORTANT:The export feature is not a backup tool. The export feature is designed to handle configuration information applicable to all members of a cluster, and network IP addresses and DNS names are filtered out during the import. (The server-specific information that is filtered out is the information you set specifically for each member in a cluster.) If you want a copy of all configuration information, including server-specific information, you need to perform a backup. See Section 2.0, Backing Up and Restoring Components.
When exporting the file, you can select to password protect the file, which encrypts the file. If you are using the exported file to move an Access Gateway from a staging area to a production area and you need to change the names of the proxy services and DNS names from a staging name to a production name, do not select to encrypt the file. You need a simple text file so you can search and replace these names. If you select not to encrypt the file, remember that the file contains sensitive information and protect it accordingly.
The following sections explain this process:
In the Administration Console, click > > .
Click > .
(Conditional) If you want to encrypt the file, fill in the following fields:
Password protect: Select this option to encrypt the file.
Password: Specify a password to use for encrypting the file. When importing the configuration onto another device, you are prompted for this password.
Click , then select to save the configuration to a file.
The filename is the name of the Access Gateway with an xml extension.
(Conditional) If you want to change the names of the proxy services and their DNS names from a staging name to a production name, complete the following:
Open the file in a text editor.
Search and remove the staging suffix.
If you have specified DNS names with a staging suffix (for example, innerwebstaging.provo.novell.com), you can search for staging.provo.novell.com and remove staging from the name.
In particular, you need to change the following:
Any fully qualified DNS names from the staging name to the production name (DNSName elements in the file).
The cookie domains associated with each proxy service (AuthenticationCookieDomain elements in the file)
The URL masks in Pin Lists that contain fully qualified names (URLMask elements in the file.
Depending upon your naming standards, you might want to change the names of the following:
UserInterfaceID elements (proxy service, pin list, and protected resource user interface ID's)
Description elements (proxy service, pin list, and protected resource descriptions)
Name (proxy service, pin list, and protected resource names)
SubServiceID elements
MultiHomeMasterSubserviceIDRef elements
LogDirectoryName elements
ProfileIDRef elements
ProtectedResourceID elements
ProfileID elements (TCP Listen options name)
(Conditional) If your Web servers in the staging area have different IP addresses and host names than the Web Servers in the production area, you can search and replace them in the configuration file or wait until after the import and modify them in the Administration Console.
Export the policies used by the Access Gateway. In the Administration Console, click > , then either select to include all policies or individually select the policies to export.
You need to export all Access Gateway policies and any Role policies used by the Access Gateway policies.
Click and modify the proposed filename if needed.
Click , then select to save the policy configurations to a file.
(Conditional) If you have created multiple policy containers, select the next policy container in the list, and repeat Step 6 through Step 8.
The policies for each container must be saved to a separate export file.
(Conditional) If your policies redirect users to staging URLs when they are denied access, search and replace these URLs with the production URLs. Open the policy file with a text editor and search for your staging name.
Copy the Access Gateway and policy configuration files to a place accessible by the new Access Gateway.
Continue with Section 15.12.2, Importing the Configuration.
Verify that the Access Gateway meets the conditions for an import:
The Access Gateway should not be a member of a cluster. If it is a member of a cluster, remove it from the cluster before continuing.
In the Administration Console, click > , select the Access Gateway, then click > .
You can create a cluster and add this machine to the cluster as the primary server after you have completed the import.
The Access Gateway should be an unconfigured machine. If it contains reverse proxies, delete them before continuing.
In the Administration Console, click > > > . In the , select , then click . Update the Access Gateway and the Identity Server.
In the Administration Console, click > .
The policies that the Access Gateway is dependent upon must be imported first.
(Conditional) If you have exported policies from more than one container, create the policy containers. Click the icon; in the , click , specify the name for the container, then click .
(Conditional) If your system already contains policies, delete them if they aren’t being used.
If they are in use and you have policies with the same names as the policies you are going to import, you need to manually reconcile the duplicate policies. See Step 5 in Section 15.12.3, Cleaning Up and Verifying the Configuration.
In the Policy List, click .
Browse to the location of the policy configuration file, select the file, then click .
(Conditional) If you exported multiple policy configuration files, repeat Step 5 and Step 6.
Enable all new Role policies. Click > > .
Either select to enable all policies or individually select the policies, then click .
Click , then click .
To import the Access Gateway configuration, click > > > .
Browse to the location of the file, select the file, enter a password if you specified one on export, then click .
Continue with Section 15.12.3, Cleaning Up and Verifying the Configuration.
When the configuration import has finished, verify the configuration for your reverse proxies.
Click > > .
Verify the listening address.
This is especially important if your Access Gateway has multiple network adapters. By default, the IP address of eth0 is always selected as the listening address.
Verify the certificates assigned to the reverse proxy.
The Subject Name of the certificate should match the published DNS name of the primary proxy service in the .
Verify the Web Server configuration. In the, click the link. Check the following values:
Web Server Host Name. If this name has a staging prefix or suffix, remove it.
IP addresses in the Web Server List. If the IP addresses in the production area are different from the IP addresses in the staging area, modify the IP addresses to match the production area.
Certificates. If you have configured SSL or mutual SSL between the proxy service and the Web servers, configure the and options. The export and import configuration option does not export and import certificates.
Click twice.
(Conditional) If you have multiple reverse proxies, repeat Step 1 for each proxy service.
On the Configuration page, click , then select the configuration.
If you have multiple reverse proxies, verify that the Reverse Proxy value in the section is the reverse proxy you want to use for authentication, then click twice.
(Conditional) If the Administration Console already contained some policies, verify that you do not have policies with duplicate names. Click > .
Policies with duplicate names have Copy-n appended to the end of the name, with n representing a number. If you have duplicates, reconcile them:
If they contain the same rules, you need to reconfigure the resources using one policy to use the other policy before you can delete the duplicate policy.
If they contain different rules, rename the duplicate policies.
(Conditional) Apply any policy configuration changes.
Click > .
Click > .
Configure the keystores for the Access Gateway.
If you have configured the Access Gateway for SSL between the Identity Server and the Access Gateway and between the Access Gateway and the browsers, verify that the trust stores and the keystores contain the correct certificates.
In the Administration Console, click > .
Find the certificate for the Access Gateway.
The subject name of this certificate should match the DNS name of the Access Gateway. If this certificate is not in the list, you need to create it or import it.
This certificate should be in use by the ESP Mutual SSL and Proxy Key Store of the Access Gateway.
If the certificate is not in use by the required keystores, select the certificate, then click > .
Click the icon, select ESP Mutual SSL and Proxy Key Store of the Access Gateway, then click twice.
Configure the trust stores for the Access Gateway.
In the Administration Console, click > > .
The trusted root certificate of the CA that signed the Access Gateway certificate needs to be in the NIDP-truststore.
The trusted root certificate of the CA that signed the Identity Server certificate, needs to be in the ESP Trust Store of the Access Gateway.
If you need to add a trusted root to a trust store, select the trusted root, click .
Click the icon, select the required trust store, then click twice.
(Optional) Create a cluster configuration and add this server as the primary server.