In this exercise, you and a partner will configure your systems for policy server failover. You will change your environment as shown in the picture above. You will need to perform the following steps:
- Setup common policy and key stores. The machine that houses the common policy store will be designated the “primary” machine. The other machine will be the “secondary” machine.
- Configure the host configuration object, HostSettings1, for failover. Both trusted hosts will use the same host configuration object.
- Ensure that both clients are registered as trusted hosts in the common policy store. The primary machine is already registered; you will need to register the secondary machine.
- Ensure that both policy servers are listed as bootstrap policy servers in the client machine’s smhost.conf files.
- Get the IP addresses for both policy servers
- Decide which server will serve as the primary
- Stop the secondary policy server’s services
- Reconfigure the secondary policy server to use the primary, common policy store and key store.
- NOTE: This step assumes that common names were used for both:
- Host Configuration Object
- Agent Configuration Object
- If names do not agree, the secondary partner’s WebAgent.conf and SMHost.conf files must be edited to use the correct object names
- NOTE: This step assumes that common names were used for both:
- Restart the secondary policy server
Once you have completed this step, both machines will be pointing to common policy and key stores. This means that the policy store can be modified by either partner. Be sure you coordinate any administrative changes to that only one partner is modifying the policy store at a time.
Also, the secondary partner’s trusted host will not be able to communicate with a policy server, because the trusted host is not yet registered in the common policy store. The secondary partner’s web server will not function at this point.
The above diagram shows the use of the Policy Server Management Console’s Data tab to reconfigure the secondary policy server to use the common policy store, located on the primary machine.
This slide shows the use of the Policy Server Management Console’s Data tab to reconfigure the secondary policy server to use the common key store, located on the primary machine.
Part 2: Configure the Host Configuration Object for failover
- Edit the Host Configuration Object
- Set the PolicyServer parameter to contain a multi-valued list of both policy server IP addresses
- List the primary policy server first
- Ensure that EnableFailOver is set to YES
- Save the configuration changes
This step can actually be performed by either partner, since both partners are pointing to a common policy store.
Part 3: Register the secondary client as a trusted host
- Use smreghost on the secondary machine to register the secondary client machine as a trusted host in the common policy store
- Copy the new SMHost.conf file from:
To
<web agent install directory>\config directory
These steps are performed by the partner owning the secondary machine.
Use smreghost to register the secondary client machine as a trusted host. Specify the name of the Host Configuration object in the common policy store (e.g., TranspolarHostSettings). The smreghost tool will create a new SMHost.conf file in the directory from which the tool is run (e.g., the bin directory). You will need to copy this file into the web agent’s configuration directory (replacing the one that is already there).
Reregistering a Trusted Host using smreghost:
- Reasons to reregister include:
- renaming trusted host
- recreating deleted trusted host
- creating trusted host entry in new policy store
- changing the shared secret
- recreating SMHost.conf file
- To reregister, use the smreghost tool located in:
<agent_install_location>/bin
When you install a Web Agent on a server for the first time, you are prompted to register that server as a trusted host. Once the trusted host is registered, you do not have to re-register with subsequent Agent installations. There may be situations when you want to re-register a trusted host independent of an Agent installation, such as:
- To rename the trusted host if there has been a change to your SiteMinder environment.
- To register a trusted host if the trusted host has been deleted in the Policy Server User Interface.
- To register a trusted host if the trusted host policy objects have been deleted from the policy store or the policy store has been lost.
- To change the shared secret that secures the connection between the trusted host and the Policy Server.
- To recreate the SmHost.conf configuration file if it is lost. To re-register a trusted host, use the Registration Tool, smreghost. This tool is installed when you install an Agent on a trusted host, and is located in the directory <agent_install_location>/bin.
smreghost –i policyserver.abc.com:44443 –u TrustedHostAdmin –p password -hn MyWebServer –hc MyHostSettings
i IP address of the Policy Server where you are registering this host. Specify the port of the authenti-cation server only if you are not using the default, which is 44442. If you specify a port number, which can be a non-default port, that port is used for all three Policy Server servers (authentication, authorization, accounting), however, the unified server responds to any Agent request on any port. The policyserver entry in the SmHost.conf file will be: "112.11.2.5,5555,5555,5555"
-u Name of the SiteMinder administrator with the rights to register a trusted host.
-p Password for the Administrator allowed to register a trusted host.
-hn Name of the host to be registered. This can be any name that identifies the host, but it must be unique. During registration, a trusted host object with this name is created in the policy store.
-hc Name of the Host Configuration Object configured at the Policy Server. -rs Enable shared secret rollover (this is the default).
-f Full path to the file that contains the registration data. The default file is SmHost.conf. If you do not specify a path, the file is installed in the location where you are running the smreghost tool. If you use the same name as an existing host configuration file, the tool backups up the original and adds a .bk extension to the backup file name. On Windows systems, if you specify a file path with spaces, the entire path must be enclosed in quote marks.
-cp Name of the cryptographic provider you are using for encryption. BSAFE is the default.-cd Full path to the PKCS11 DLL. This DLL is installed with the nCipher software installed on same Web server as the Web Agent. (required for PKCS11 encryption)
-ct Token label for the hardware token. Only use this argument if there is a token label. (optional for PKCS11 encryption)-ck Passphrase for the token. (required for PKCS11 encryption)
The above pic shows the use of the smreghost utility to register a new trusted host with a policy server and generate a new SMHost.conf file with a new shared secret. The SMHost.conf needs to replace the existing SMHost.conf in the <web agent install directory>\config directory. It is a good idea to preserve the original SMHost.conf first.
This pic shows that both partners’ trusted hosts have been registered in the common policy store.
NOTE: To enable the viewing of Trusted Hosts under the System Configuration first select the View menu on the menu bar and select the Trusted Hosts item on the menu.
Part 4: Configure multiple bootstrap policy servers
- Both partners: Place an entry for both policy servers in your SMHost.conf files <
- Restart the web servers to allow allow their trusted hosts to download their configurations from the primary policy server
NOTE: It is assumed that common names were used for the Agent Configuration Object (e.g., AgentSettings1). When the agents connect to the primary policy server (via their trusted hosts), they will attempt to fetch the Agent Configuration Object settings specified in their WebAgent.conf file. You may need to edit the WebAgent.conf file to ensure that the appropriate Agent Configuration Object is named there. In addition, at this point, both agents will connect using the same default agent identity listed in the Agent Configuration Object.
This pic shows the SMHost.conf file. This file is used to bootstrap the trusted host’s connection to a policy server, from which it can download configuration object data. This example contains two policy server entries for the support of failover during the bootstrapping phase.
The policyserver parameter specifies the Policy Server(s) to which the trusted host will try to connect. To implement failover, enter more than one Policy Server IP address, placing each entry on its own line.
For example:
policyserver="123.122.1.1,44443"
policyserver="123.122.1.2,44443"
policyserver="123.122.1.3,44443"
If a Policy Server has been removed from your SiteMinder environment or is no longer in service, remove it by deleting the entry.
Note: When the smreghost generates the SmHost.conf file, it lists three ports for the bootstrap policy server: 44443, 44443, 44443. Only one port need be listed if this trusted host is hosting only 6x Web agents.
Test the new failover configuration:
NOTE: These tests should be performed by one partner at a time. It is vital that both partners’ policy server debugging is enabled.
- Open a browser and access a protected resource
- Close your browser
- Stop the primary policy server’s services
- Re-open your browser and re-access the protected resource deployed on your web server
- Close your browser
- Stop and restart your web server
- Re-open your browser and re-access the protected resource
Step 1 tests that you can access a resource via the primary policy server in the new configuration.
Steps 3-4 tests failover of the operational policy server. Since the primary policy server is down, successful access of a protected resource will involve requests being routed to the secondary policy server.
Steps 6-7 tests failover of the bootstrap policy server. Since the primary policy server is down, the trusted host on your web server will not be able to bootstrap off it. If the web server is able to start up successfully, then the trusted host was able to bootstrap off the secondary policy server.
Centralized Agent Configuration:
- At this point:
- Your trusted hosts share the same Host Configuration Object
- Your agents share the same Agent Configuration Object
- Your agents share the same agent identity
- Each agent can have its own identity
Once you have completed the failover exercise, each trusted host will be sharing a single Host Configuration Object. This allows you to centrally manage the settings for your hosts. For example, in order to add or remove a policy server, or change from failover to round robin mode, you only need to edit this single object.
In addition, each agent is using the same Agent Configuration Object. Again, the benefit of this setup is that changes to agent parameters can be made centrally in one place; all agents that use the same configuration object will get the updated changes.
However, your agents are connecting to the policy server using the same agent identity (the one specified as the DefaultAgentName in the Agent Configuration Object). You can continue to operate in this manner, or you can create distinct agent identities for each agent, and have your agents connect as those distinct identities. Which method you choose to employ is up to you. If you have multiple agents connecting as the same agent identity, your audit logs, for example, will not be able to distinguish among your agents. However, if you have a very large web farm, it may not be practical to create an agent identity for each agent in the farm. In such cases, you may want to create a single agent identity that represents a specific web application or server farm and have all agents in the application/farm share that identity.
In the next page, we will show you how to set up your system so that multiple agents can connect as different agent identities, but still share the same Agent Configuration Object.
Multiple Agent Identities >>
