This document is a deployment guide for RCDevs WebADM in high availability (or cluster) mode. The reader should notice that this document is not a guide for installing WebADM applications (Web Services and WebApps).
2. Product Overview
WebADM is a powerful Web-based LDAP administration software designed for professionals to
manage LDAP Organization resources such as Domain Users and Groups. It is the configuration
interface and application container for RCDevs Web Services and WebApps such as OpenOTP.
WebADM requires an LDAP directory as back-end user store and a SQL database for logs and
end-user message customizations. WebADM is compatible with Novell eDirectory, OpenLDAP,
RCDevs Directory Server and Microsoft ActiveDirectory 2003⁄2008.
3. System Requirements
The current version of WebADM runs on Linux 32bit or 64bit operating systems with GLIBC >= 2.5. The installation package contains all the required dependencies allowing WebADM to run on any Linux-based system without other requirements. WebADM only needs an LDAP backend (Novell eDirectory, OpenLDAP, RCDevs Directory Server, Microsoft ActiveDirectory, or Oracle Directory) and a SQL backend (MySQL, PostgreSQL, Oracle or Microsoft SQL).
For running WebADM and its applications, as well as the OpenOTP Radius Bridge server and
RCDevs Directory Server, your system should fit the following requirements:
A dedicated server computer or Virtual machine with Linux GLIBC >= 2.5 (RedHat, Centos, SuSe
Debian, Ubuntu).
2 GHz processor (multi-core / multi-thread processor is highly recommended).
Both 32 and 64-bit chips are supported provided that 32 libraries are present.
2GB RAM memory.
2GB disk space for installation files.
Network access with DNS and NTP integration.
A local or remote LDAP directory server (RCDevs Directory Server, OpenLDAP, Novell eDirectory or Microsoft ActiveDirectory >= 2003). WebADM for ActiveDirectory 2003 has some limitations which do not exist with ActiveDirectory 2008. Always prefer using ActiveDirectory 2008 with WebADM.
A local or remote SQL database server (MySQL, PostgreSQL). Oracle and MS SQL Server support are included but setup might require manual table creation.
Outbound Internet access for checking versions, connecting SMS gateways and sending emails.
A local mail transfer agent (Sendmail or Postfix).
Firewall open ports: 80, 443, 8080, 8443, 1812.
Some other ports are required for cluster node communications as described later.
4. High Availability Mechanisms
Warning
Starting from WebADM version 1.4.2, any high availability and clustering feature
require an RCDevs Enterprise license. Without a valid license file, the HA and cluster
features are automatically disabled.
WebADM supports several high-availability mechanisms for internal and external service failover and for the whole system redundancy. It supports connecting several external data sources such as LDAP directories and SQL databases at the same time and does automatic failover. WebADM connects by default the first declared service (LDAP / SQL / Session Manager / Proxy) and transparently switches to a secondary service in case of primary service failure.
For systems requiring high-availability and near-zero downtime, WebADM supports cluster setup. In cluster mode, the whole system and services can be deployed on two or more servers for ensuring global redundancy, failover and even load-balancing functionalities.
4.1 Connecting Redundant External Services
To enable more than one connection to external services, you just need to configure the external services’ connections in the /opt/webadm/conf/servers.xml configuration file. WebADM will automatically check for service responsiveness in the order the services are specified. It will also connect the first declared service in priority but if this service goes down, it will try to connect the next responsive service. When connected to a non-primary service, WebADM will re-check if the primary service has recovered every minute. If at one moment, the service goes up again, WebADM will reconnect its primary service immediately.
The external service switching works for any server connection defined in the /opt/webadm/conf/servers.xml file. Failover is done transparently by WebADM and your client systems and end-users won’t be affected by the automatic external service switching.
Note
The WebADM session manager and PKI server are specified in the servers.xml file but are local WebADM services (part of the WebADM software).
4.1.1 Connecting Two LDAP Servers
In this example, WebADM uses “LDAP Server 1” by default and switches to “LDAP Server 2” in
case “LDAP Server 1” goes down.
<LdapServer name="LDAP Server 1"
host="server1"
port="389"
encryption="TLS" />
<LdapServer name="LDAP Server 2"
host="server2"
port="389"
encryption="TLS" />
It is mandatory that the two LDAP servers use replication. This is automatic with Active Directory when using two domain controllers in the same domain or with Novell eDirectory when LDAP partition replication is set up. RCDevs Directory Server an OpenLDAP require LDAP replication configuration. Please refer to the OpenLDAP documentation for OpenLDAP replication.
Remark
Local LDAP connection does not need a security transport layer. Yet, remote LDAP
connections should use SSL or TLS if there is a risk of network packet sniffing between the
servers.
The LDAP server (Novell eDirectory, OpenLDAP or RCDevs directory server) can be installed and
run on one or several of the cluster nodes. They can be deployed on another dedicated server too.
4.1.2 Connecting Two SQL Servers
The following example illustrates two redundant SQL servers.
<SqlServer name="SQL Server 1"
type="MySQL"
host="server1"
user="webadm"
password="rwebadm"
database="webadm" />
<SqlServer name="SQL Server 2"
type="MySQL"
host="server2"
user="webadm"
password="rwebadm"
database="webadm" />
It is preferred that SQL databases use replication but this is not a requirement. It’s a requirement if you use Hardware Tokens with WebADM because Token inventory is stored in the SQL.
4.2 Installing WebADM In Cluster-Mode
All the components in WebADM have been designed to support clustering. In this case, the
WebADM components (i.e. the WebADM and Radius Bridge software) are deployed on several
server computers to provide redundancy, failover or load-balancing.
4.2.1 WebADM Internal Components
A WebADM server includes several internal components. These components are local TCP/IP
network services (just like the external services) started by the WebADM startup script and part of
the base installation. They must be correctly configured for working in cluster mode.
The HTTP and SOAP server
The internal Web server provides the SOAP-based web services on port HTTP 8080 and HTTPS
8443. And it provides the Admin Portal and end-user WebApps on HTTPS port 443. SSL server
certificates are automatically generated during the initial setup by an internal self-signed certificate authority (CA).
In cluster mode, all the services running over SSL/TLS must have certificates issued by one
central certificate authority. And only one cluster node will play the role of the certificate authority. It is a requirement that all the HTTPS services which provide authentication based on client certificates, trust the client certificates issued centralized CA.
The session manager
This component handles all the user sessions initiated by the web services such as OpenOTP and the WebApps. Even if multiple session managers can be specified on each node for failover purposes, in cluster mode, only one session manager should be used for all the cluster nodes at one moment. This is required for the cluster session sharing system to ensures clients requests will be handled correctly whatever node is used and to ensure user data integrity remains consistent. The session manager is used by the cluster nodes to communicated internal information too, such as configuration updates.
Note
With WebADM >= 1.2.6-1, the session manager supports automatic synchronous
replication. Session data are replicated in real-time between the two first session servers in your configuration. Failover to the secondary node does also not break running sessions.
Web services’ sessions are also shared for the whole cluster so that internal user working data and user locks remain coherent over your cluster service nodes.
The WebADM WebApps use the session manager to handle user login sessions too. This has the
big advantage that user browser requests can come randomly to any HTTP service node without
impacting the system or the client. This is very handy for working with round-robin load-balancers in front of the service nodes.
The PKI server
One node is assigned the certificate authority role. It will run the WebADM Rsignd service which provides certificate signing for the local node and for your other cluster node. The PKI is required during the setup of your cluster nodes for generating SSL server certificates and configuring local CA trusts. It is used by the Admin Portal and the WebApps for issuing and renewing administrator and WebApp user certificates too.
5. Cluster Setup
In this section, we will describe how to set up a cluster configuration for WebADM and Radius
Bridge. The cluster will provide redundant web services (ex. OpenOTP), WebApps and RADIUS
authentication services.
5.1 Installing The First Node
The first node of your cluster is a standard WebADM installation and there is nothing specific to be configured on your first WebADM system. Yet, some firewall ports will have to be opened for allowing the others nodes to communicate with the internal services such as the session manager and PKI server.
The setup of the primary node is started with the command /opt/webadm/bin/setup. The setup will initiate the CA, create local service certificates, setup permissions, etc…
The configuration of the servers.xml file will contain the following information:
LDAP Servers:
LDAP 1
LDAP 2
SQL Servers:
SQL 1
Session Manager:
Localhost
<secondary server>
PKI Server:
Localhost
In this example, we connect two LDAP servers for redundancy and only one SQL server.
The Radius Bridge is installed on the same server running WebADM and uses the following
OpenOTP URL in the /opt/radiusd/conf/openotp.conf: http://localhost:8080/openotp/
5.2 Installing A Secondary Node
The node is installed with the self-installer packages like with the primary node but the setup script must be run using the slave parameter with the command: /opt/webadm/bin/setup slave.
The setup can be re-run on an existing installation. You can also install a second VMWare
appliance and re-run its WebADM setup script after installation for adding the node to your cluster.
The secondary node should use the same configuration files as the primary node. You can copy
the /opt/webadm/conf/webadm.conf file from the primary node. Special attention should be given to the LDAP encryption key which must be the same on all your cluster nodes.
The /opt/webadm/conf/servers.xml should use the same LDAP / SQL servers and in the same
order.
The session management services will be running on both servers but only one of them must be used at a time by both servers. The two session managers can also be specified in the servers.xml files, but in the same order. It is possible to use the local session manager on both servers when both WebADM servers are used in failover only and are never used at the same time.
The PKI server will not be set up nor run on the secondary server. The server will use the primary server PKI. During the setup in slave mode, the script will ask for the IP address, port number and secret of the primary server PKI. It will communicate with the remote PKI to initialize its SSL certificates ad CA trusts.
Proceed with the following steps for your secondary node installation:
1) On the primary server, allow client PKI connections to the Rsignd PKI server.
This is done by adding a client configuration block for the secondary server in the /opt/webadm/conf/rsignd.conf file:
Restart the WebADM server with the command: /opt/webadm/bin/webadm restart.
2) On the primary server, you must allow network communication to the session manager and PKI server ports from the secondary server. On Linux edit the /etc/sysconfig/iptables file and the line:
# Port for PKI server
-A INPUT -p tcp -m tcp -s <secondary node IP> -j ACCEPT --dport 5000
# Port for Session Manager access & session replications (for WebADM >= 1.3.x)
-A INPUT -p tcp -m tcp -m multiport -s <secondary node IP> -j ACCEPT --dports 11211,11212
-A INPUT -p udp -m udp -m multiport -s <secondary node IP> -j ACCEPT --dports 11211,11212
# Port for Session Manager access & session replications (for WebADM 1.4.x)
-A INPUT -p tcp -m tcp -s <secondary node IP> -j ACCEPT --dport 4000
Port TCP 5000 is used for the PKI server.
Port TCP 11211 is used for the session manager on WebADM 1.3.x.
Port TCP 4000 is used for the session manager on WebADM >= 1.4.x.
Also add a firewall rule for SOAP services inter-communications:
3) On the secondary server, run the setup script in slave mode with the command:
/opt/webadm/bin/setup slave
You will be asked for the PKI server IP address, port, secret. The address is the primary node IP. The port is 5000. And the secret is ‘secret’ or the secret you have defined in the /opt/webadm/conf/rsignd.conf file on the primary server for the secondary server client.
The SSL certificates are generated on the primary node and the CA certificate is installed in the local CA trust list.
4) On the secondary server, configure the /opt/webadm/conf/servers.xml file to use the session manager and PKI server from the primary server.
Note here that the first declared session manager is the primary server. And there is no PKI server redundancy.
5) On the secondary server, add the firewall rules to allow communications from the primary
server.
# Ports for Session Manager access & session replications
-A INPUT -p tcp -m tcp -s <primary node IP> -j ACCEPT --dport 4000
# Ports for WebADM SOAP server
-A INPUT -p tcp -m tcp -m multiport -s <primary node IP> -j ACCEPT --dports 8080,8443
You can now start the WebADM server on the secondary node.
IMPORTANT: If you get a message like “Connected Session server: ERROR (no servers available)”
when starting the WebADM server, then be sure the TCP port 4000 is correctly opened in both directions (on both server for the other node IP). You can do the following command to check if the remote port is opened.
telnet <Other Node IP> 4000
6) On the secondary node, configure the Radius Bridge exactly like on the primary node.
You cluster configuration will look like this:
5.3 LDAP Replication
LDAP replication may differ according to the chosen LDAP implementation. With Active Directory, replication is handled by the Domain Controllers. With Novell eDirectory, replication requires a partition to be set up and replication should be configured with Novell eManager.
With RCDevs Directory Server and more generally with OpenLDAP, the replication uses the
syncprov overlay. The recommended is a master-master mirror configuration.
On the master node, edit the /opt/slapd/conf/slapd.conf file, uncomment the replication block and configure it this way:
Depending on your cluster usage (failover+load-balancing or failover only), you may configure and use your systems in different manners. The two scenarios explained below are the most common
use of WebADM cluster. Yet other configurations are possible and you may understand in details how WebADM services and connectors work in order to fine-tune your cluster setup.
6.1 Load-balanced + Failover WebADM Cluster
This is the scenario which corresponds to our previous example. Both WebADM servers, Web
services, WebApps can be used at the same time. The remote services (LDAP servers and SQL servers) should be used in the same order by both servers and they need to be replicated. Unless the LDAP servers use a real-time replication, it is required to use one (and the same) server at a time. Else the user data on the LDAP store could become inconsistent on the different nodes of your cluster during the LDAP replication delay.
The session management services must be used in the same order too. This is required for session sharing and cluster-level operation locking since both WebADM servers are supposed to randomly handle client requests at the same time.
The PKI server runs on the primary WebADM server only. The second server is configured to
contact Server 1 for any PKI operation. This is a requirement in any cluster installation since there can be only one certificate authority on the cluster. Note that having the PKI service down does not impact the normal operations of the cluster.
In this mode, only the primary WebADM server is used in a normal situation. The secondary server ensures redundancy and is used only in the event where the primary server is not available.
The remote services (LDAP servers and SQL servers) can be used in the same order or in a different order. This is not important since the two cluster nodes are not used at the same time and do not require a real-time LDAP data consistency. With clusters having the LDAP services deployed directly on the cluster nodes (Ex. RCDevs Directory Server), both servers may be connected to their local LDAP only.
Both servers can use their local session manager only as they do not need to share sessions and distributed locks.
The PKI server still needs to be run on the primary WebADM server only (for the same reasons as explained previously).
Your client applications using WebADM services or RADIUS can now use both cluster nodes,
either at the same time with a round-robin policy for load-balancing, or in failover mode.
7.1 Web Application Using SOAP
Your web application can make SOAP calls to any web service node. With the shared session
manager, client requests can come to any of the nodes, even if they are part of the same
sequential OpenOTP authentication session.
7.2 VPN Server Using RADIUS
The VPN client can send RADIUS requests to any of the cluster nodes. With the shared session
manager, even sequential RADIUS operations such as Challenge-Responses can come to any of
the nodes.
7.3 End-user WebApps
The WebApps can be deployed on cluster nodes like the web services and RADIUS services. The
shared session manager will ensure that user sessions are opened and synchronized on any of
the cluster nodes and client accesses can even come randomly to any of the cluster nodes.
8. Dedicated Node Roles
WebADM is composed of several components which can be assigned to a specific node in your
cluster. You can disable a component (and also a role) on a node by editing the /opt/webadm/conf/ webadm.conf file.
The Admin Portal: It is preferred to have an internal node dedicated to server administration and
to disable the Admin Portal on the front-end nodes especially when the HTTP services for
WebApps are exposed on the Internet. If the Admin node uses the common session manager, it
will be able to inform all the other nodes of an LDAP configuration change immediately (ex.
OpenOTP setting update).
The WebApps: They can be deployed on the internal network or on the public network of the
company (i.e. The DMZ) to be used by the users from the Internet.
The web services: It is preferred not to allow public access to the SOAP services and RADIUS
services. You should enable connections from the local client applications only. And you should
allow remote client accesses only through secure connectivity networks such as IPSec transport.
The RCDevs SMSHub web service can be deployed on one node and serve the role of internal
SMS gateway when used with multiple OpenOTP service nodes.
