What is WebADM?

Overview

WebADM is a powerful Web-based LDAP administration framework installed on Linux systems and designed for professionals to manage LDAP organization resources such as Domain Users and Groups.
It is the framework which orchastrate interface and application server for RCDevs Web Services and Web Applications such as OpenOTP, Spankey, Self-Services...

WebADM can be used standalone, as a powerful LDAP management console. It provides a hierarchical view of LDAP Organizations and many features for managing LDAP users and groups resources.
It includes delegated administration (administrators can be created at different levels of the tree structure, with different privileges and views), supports multiple LDAP servers simultaneously, Domains, allows multiple authentication modes, provides comprehensive SQL and file-based audit trails, etc...

WebADM is compatible with Novell eDirectory, Microsoft Active Directory 2008 and higher, OpenLDAP, FreeIPA, DS389, Oracle/Sun Directory and RCDevs Directory Server. Other directories might work but are not tested or officially supported by RCDevs.

WebADM comes up with the following embedded components:

• Apache: HTTP server for WebADM, its Web services and Web applications.
• Redis: Redis is used for session management and replication in High Availability mode.
• Watchd: Watchd component manages monitoring and failover of services configured with WebADM like LDAP, SQL, Redis, SMTP... if any issue make a service unavailable, Watchd order to all WebADM nodes to switch to another servers.
• Rsignd: Public Key Infrastructure service. During the setup, you will be prompted to make WebADM a Subordinate CA of an existing Root/Enterprise CA or to configure WebADM as Standalone CA. Both setup can be achieved in Standalone or High Availability deployment and must be considered before the WebADM setup. The default setup is to configure WebADM as a Standalone CA. More advanced setup involves configuring WebADM as a subordinate certificate authority.

All these services are mandatory and cannot be separated from the WebADM component. Every WebADM server deployed will provide these components.

System Requirements

The current version of WebADM runs on any 64-bit operating system with GLIBC >=2.5. The installation package contains the required dependencies, allowing WebADM to run on any Linux-based system without additional requirements. WebADM only needs an LDAP backend (Novell eDirectory, OpenLDAP, RCDevs Directory Server, or Microsoft Active Directory) and a SQL database (MySQL, MSSQL, MariaDB, PostgreSQL, Oracle, SQLite). Other LDAP and SQL backends might work but are not officially supported. The SQL service is generally deployed on the WebADM nodes but can also be remote, same for LDAP services and the RADIUS component. Web services like OpenOTP and web applications like Selfdesk must be installed on WebADM nodes.

To run WebADM and its services/applications, as well as the Radius Bridge Server and RCDevs Directory Server, your system should have the requirements explained in the following servers provisioning documentation:

• A dedicated server computer or Virtual machine with Linux GLIBC ≥ 2.5 (RedHat, CentOS, Debian, Ubuntu, SUSE).
• Network access with DNS and a working NTP integration.
• A local or remote LDAP directory server (RCDevs Directory Server, OpenLDAP, Novell eDirectory or Microsoft ActiveDirectory ≥ 2008).
• A local or remote SQL database server (Ex. MySQL, PostgreSQL, Oracle, SQLite).
• Outbound Internet to https://cloud.rcdevs.com
• An LDAP service account with permissions described in LDAP ACLs documentation;
• An administrative user/group that will manage WebADM and its components with permissions described in super_admins ACLs documentation.

LDAP Concepts

WebADM relies on LDAP and you should be familiar with LDAP servers or know the basics of LDAP/AD administration in order to set up WebADM correctly.

Unlike other software, there is no “admin account” to be created in WebADM. Instead, you will log in with your LDAP administrator account in the WebADM Administrator interface/portal. The WebADM administrator account (super_admin) is also generally your existing LDAP server’s administrator account. So the only accounts (admin or user) with WebADM are LDAP accounts.

When you log in WebADM, you use an LDAP administrator account (super_admin). The LDAP permissions and views inside WebADM also correspond to the LDAP permissions (ACLs) as configured and enforced by your LDAP server. This is also an LDAP configuration and not a WebADM configuration.

The WebADM proxy_user is an LDAP service account which is used by WebADM to connect the LDAP server by itself (out of an admin session). For example, OpenOTP Server needs to search users and read/write user metadata on the LDAP users. The proxy user is used by WebADM for such operations and also need sufficient LDAP permissions to handle these tasks.

WebADM requires a configuration container (CN) or an Organizational Unit (OU) to store most of its configurations. The WebADM Administrator needs read/write access to this configuration container. All configuration objects, such as policies, web services, web applications, domains, mount points, administrator roles, and option sets... are LDAP-based objects. Access to these objects, as configured through WebADM, relies on the availability of the LDAP backends. Without access to the LDAP infrastructure, WebADM cannot function or be accessed.

WebADM and all its dependencies can handle multiple and different LDAP infrastructures simultaneously. In these scenarios, there is always a primary LDAP infrastructure configured with WebADM. The configuration container mentioned earlier is stored only in the main LDAP infrastructure. Other LDAP infrastructures are referred to as LDAP mountpoints, and no configuration objects are stored in these LDAP mountpoints. Any WebADM data (such as token information, user certificates) or settings (such as token methods, OTP fallback methods) are stored in the corresponding LDAP objects of the mountpoint.

If, for any reason, WebADM data and settings cannot be stored directly in the corresponding LDAP infrastructure, there are two alternatives:

• Configure WebADM in Read-Only mode: In this mode, the necessary data will be stored in the RCDevs Directory and an SQL database (this option is not preferred).
• Configure LDAP synchronization: Utilize the APIs provided by WebADM to synchronize with the RCDevs Directory, and store data and settings within the synchronized objects in the RCDevs Directory. If multiple LDAP synchronizations are configured, each must occur at a dedicated level within the LDAP tree to avoid conflicts between them.

Starting from version 2.3.20, WebADM natively supports object synchronization (users and groups) from cloud IAM providers such as EntraID, Okta, PingOne, and others.

High Availability concepts

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. A WebADM cluster is an Active-Active cluster. Any nodes can be contacted at any time for administration or services purposes.

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-watchd will re-check if the primary service has recovered every 10 seconds. 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.

The WebADM session manager and PKI server are specified in the servers.xml file but are local WebADM services (part of the WebADM software). PKI Service (Rsignd) is running on all nodes since WebADM version 2.2.3.

Configuring two or more 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 and OpenLDAP require LDAP replication configuration. 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 service (Novell eDirectory, OpenLDAP or RCDevs Directory) can be installed on WebADM servers or on other server(s).

Connecting two or more SQL Servers

The following example illustrates two redundant SQL servers configured in servers.xml.

<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" />

SQL databases must be replicated and configured as Master-Master. WebADM must be able to read/write data from every SQL server configured.

Failover and Clustering architecture

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. 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.

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.

Architecture for a single/multiple sites

This setup is the recommended one when the whole cluster is running on the same site. If a WebADM cluster is going to be split over multiple sites, the latency between the sites must be good in order to not impact WebADM performances.
If you want failover of WebADM service or if you have an important load, then you need to deploy 4 WebADM nodes or more, over the sites. Architectures are described below.

Single Site (2 nodes cluster)

On Server 1

LDAP Servers: LDAP 1, LDAP 2
SQL Servers: SQL 1, SQL 2
Session Manager: Server 1, Server 2
PKI Server:  Server 1, Server 2
STMP Server: Server 1, Server 2
Proxy HTTP: Server 1, Server 2

On Server 2

LDAP Servers: LDAP 1, LDAP 2
SQL Servers: SQL 1, SQL 2
Session Servers: Server 1, Server 2
PKI Server: Server 1, Server 2
STMP Servers: Server 1, Server 2
HTTP Proxy Servers: Server 1, Server 2

Single Site (4 nodes or more cluster)

Configuration designed to support very high load performance.

On Server 1

LDAP Servers: LDAP 1, LDAP 2, LDAP 3, LDAP 4
SQL Servers: SQL 1, SQL 2, SQL 3, SQL 4
Session Manager: Server 1, Server 2, Server 3, Server 4
PKI Server:  Server 1, Server 2, Server 3, Server 4
STMP Server: Server 1, Server 2...
Proxy HTTP: Server 1, Server 2...

On Server 2

LDAP Servers: LDAP 1, LDAP 2, LDAP 3, LDAP 4
SQL Servers: SQL 1, SQL 2, SQL 3, SQL 4
Session Manager: Server 1, Server 2, Server 3, Server 4
PKI Server:  Server 1, Server 2, Server 3, Server 4
STMP Server: Server 1, Server 2...
Proxy HTTP: Server 1, Server 2...

On Server 3

LDAP Servers: LDAP 1, LDAP 2, LDAP 3, LDAP 4
SQL Servers: SQL 1, SQL 2, SQL 3, SQL 4
Session Manager: Server 1, Server 2, Server 3, Server 4
PKI Server:  Server 1, Server 2, Server 3, Server 4
STMP Server: Server 1, Server 2...
Proxy HTTP: Server 1, Server 2...

On Server 4

LDAP Servers: LDAP 1, LDAP 2, LDAP 3, LDAP 4
SQL Servers: SQL 1, SQL 2, SQL 3, SQL 4
Session Manager: Server 1, Server 2, Server 3, Server 4
PKI Server:  Server 1, Server 2, Server 3, Server 4
STMP Server: Server 1, Server 2...
Proxy HTTP: Server 1, Server 2...

ldap_routing setting of webadm.conf file can be enabled in order to route the LDAP requests and not overload the primary LDAP server.

Contact RCDevs Service Team for higher design.

Primary and Disaster Recovery sites (x nodes cluster)

As all infrastructures, integrations and needs are different, involve RCDevs Service Team is highly advised to study the topology of your network, your integrations and software architecture/configuration.

Multiple Sites (x nodes cluster and x sites)

Contact RCDevs Service Team for that kind of design. Many things needs to be considered to have a working setup like sites latencies, services replications, components availabilities and so on.

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 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 the internal certificate authority. All cluster node will handle 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 server

This component handles all the user sessions initiated by 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.
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

All WebADM servers are assigned the certificate authority role in cluster installation. 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, for electronic signature, applications installations (e.g: WAProxy, Spankey client, Radius Bridge...)
During the WebADM setup script, you will be prompted to make WebADM a Subordinate CA of an existing Root/Enterprise CA or to make WebADM as Standalone CA. Both setup can be achieved in Standalone or High Availability deployment and must be concidered before the WebADM setup. The default setup is to configure WebADM as a standalone CA.

Architecture overview

Below are the DNS names and IP addresses to be used in the standalone, HA guides and the whole documentation website: