Load balancing Access Manager
Last updated
Was this helpful?
Last updated
Was this helpful?
High availability is an
Access Manager is fully supported in load-balanced environments. You can have a load-balanced web app farm, and a separate API farm, or a single farm for both.
If the load balancer 'hides' the real client IP address (e.g. a 'application/layer 7' load balancer), it must support supplying the client IP address in the X-Forwarded-For header
The load balancer must support load balancing both HTTP and HTTPS. 'SSL offloading' is not supported.
A Lithnet Access Manager enterprise edition license
At least one Windows Server 2012 R2 domain controller in the domain where AMS will be installed
The in the domain must be enabled
The same account must be used on all hosts in the farm. A group-managed service account is strongly recommended
Each host must be running the same version of the Access Manager Service at all times
An external SQL server, Azure SQL, or Amazon RDS SQL server. Using SQL express is not supported in a high availability scenario
You cannot use the built-in SQL express database instance when installing AMS for high availability, so you'll need to create your database in advance. This can be on a SQL standard or enterprise edition standalone host, or cluster, or you can deploy the database in an Azure SQL or Amazon RDS instance. See the for more information.
Make sure you provide your Enterprise edition license key, save your configuration, and restart the service before moving onto install subsequent nodes
Repeat the installation process for the next node. Make sure to use the same service account, connection string, and TLS certificate on each server.
Settings on the
Host configurationpage will need to be configured per-node. All other settings are stored centrally in the database. Therefore, you will not need to provide the license key after installing it on the first node.
If the load balancer 'hides' the real client IP address (e.g. a 'application/layer 7' load balancer), you must configure the IP address detection settings in the app. If you are using a 'transport layer' load balancer, such as Microsoft NLB, you can skip this step.
From the App configuration/IP detection page, select the option to Resolve client IP address from X-Forwarded-For headers.
If you have multiple load balancers, web application firewalls, or reverse proxies in front of the application, adjust the Maximum allowed entries in header to reflect the number of trusted devices that will be contributing to the X-Forwarded-For header value. For example, if your AMS server sits behind a load balancer farm, which sits behind a WAF farm, then enter 2 for this value.
Provide the IP address, or IP network range that the load balancer appliance (and other WAFs or proxies) sits in. This allows AMS to accurately detect which IP address belongs to the client.
Test that the configuration is working correctly, by making an access request via the web app. In audit entry that appears in the event log, you should see the correct client IP address, and not the IP address of the load balancer.
Configure the load balancer to point to the nodes of the farm.
If your load balancer provides customizable probes or health checks, see the 'Load balancer probes/Heath check` section below.
If you are load balancing the web app, the load balancer can be configured to make a HTTP GET call to the /health-check endpoint to determine host availability. A HTTP 200 OK response indicates the service is healthy. Any other response should be treated as a failure. Health check requests must be performed over HTTPS.
If you are load balancing the API host, you can make a HTTP GET call to the api/v1.0/health-check endpoint to determine host availability. A HTTP 200 OK response indicates the service is healthy. Any other response should be treated as a failure. Health check requests must be performed over HTTPS.
On the first node, follow the steps in the for configuring AMS features as appropriate for your environment.
