Overview

In this documentation, we will explain the possible configurations for scenarios where the LDAP infrastructure used with WebADM for identities and groups cannot be utilized to store WebADM data (LDAP read-only setups).

There are two possible setups to address this limitation.

Setup 1

  • The first option is to configure WebADM with RCDevs Directory Server (OpenLDAP) to store WebADM configuration objects such as Domains, Policies, LDAP Option Sets, etc. Next, set up a WebADM LDAP Mount Point to virtually integrate your LDAP infrastructure into WebADM within a container or organizational unit. User data (e.g., token metadata) and settings (user or group policies) are stored in the SQL database configured with WebADM. The drawback of this setup is that the consistency of the SQL data depends on the proper functioning of SQL replications when running a WebADM cluster. If SQL replications are disrupted, it may impact authentication and user experience. Restoring database consistency in such cases can be challenging. Another limitation of this setup occurs when moving LDAP objects (users and groups) from your IAM console. The user and group data stored in the SQL database are linked to LDAP objects based on their distinguishedName (DN) attribute. Moving an object will change its distinguishedName value. If this operation is not performed through the WebADM Framework, the DN reference in the SQL database will not be updated, causing the registered data to no longer be linked to the correct user or group. The link can be restored manually by accessing the Metadata table from WebADM Administrator Portal > Databases tab > User Metadata. From the same menu, you can use the Check User Links option to identify entries that are no longer linked to an LDAP object. This check does not remove orphaned entries; if the object still exists, you will need to manually re-link it.

This setup requires an enterprise license, which can only be issued by the RCDevs Sales team. Self-generated freeware or trial licenses are not supported, and regular enterprise licenses purchased through the RCDevs web store are also not supported.

Setup 2

  • The second option is to configure WebADM with RCDevs Directory Server (OpenLDAP) to store WebADM configuration objects such as Domains, Policies, LDAP Option Sets, and more, and synchronizing your LDAP identities and groups (e.g., from Active Directory) into the RCDevs Directory Server. Passwords can also be synced from AD to the RCDevs Directory Server. This synchronization is one-way, meaning identities will exist in two different locations. A potential limitation of this setup involves password management. If a user changes their password in AD, the corresponding password in RCDevs Directory Server will only be updated during the next synchronization. As a result, the PwReset applications provided by RCDevs cannot be used to update LDAP passwords, as the update would only apply to the OpenLDAP instance in this case. Identity/Group additions or deletions are managed in the source directory; if an object is removed from AD, it will also be removed from OpenLDAP during the next synchronization. This setup works with any kind of license.

Setup 1

Refer to the WebADM Installation Guide for instructions on how to install and set up the WebADM framework. Once WebADM is running with RCDevs Directory, you can adjust the WebADM configuration file as explained in the next section.

Adapt WebADM configuration file

Edit the /opt/webadm/conf/webadm.conf file and update the webadm_account_oclasses and webadm_group_oclasses parameters.

These settings need to be adjusted to inform WebADM of the objectClasses used by your Directory for user and group objects. For instance, in Active Directory, a user object might have person, organizationalPerson, or user objectClasses, which designate it as a user object. Configuring these values in the webadm_account_oclasses setting will ensure WebADM recognizes these objects as WebADM accounts. Similarly, the same logic applies to groups.

This adjustment is necessary because, in a typical setup, WebADM only recognizes activated objects. Activation involves adding an objectClass to a user or group to designate it as a WebADM user or group object. In a read-only LDAP scenario, where you cannot modify objectClasses on user or group objects, this configuration allows WebADM to identify the relevant objects without needing to modify them directly.

It should include the following objectClasses:

webadm_account_oclasses "person","organizationalperson","user"
webadm_group_oclasses "group", "groupOfNames", "groupOfUniqueNames", "groupOfURLs", "posixGroup"

Another setting in the WebADM configuration file that needs to be adjusted is the default datastore. By default, the datastore is set to LDAP. You need to change it to SQL so that WebADM can store user and group data in its SQL database.

data_store SQL

Once the adjustments to the WebADM configuration file are complete, restart the WebADM services for the changes to take effect.

/opt/webadm/bin/webadm restart

or

systemctl restart webadm

The next steps of this setup must be completed through the WebADM Administrator Portal.

Setup your LDAP Mount point

Refer to the LDAP Mount Point documentation to complete this part of the setup. Begin by creating a container, then configure the LDAP Mount Point object, and finally, create the associated domain object. Detailed instructions for each step are provided in the documentation. After completing these steps, you can start utilizing the identities and groups from your LDAP Mount Point.

Setup 2

Refer to the WebADM Installation Guide for detailed instructions on installing and setting up the WebADM framework. Once the WebADM framework is running with the RCDevs Directory Server, you can set up on-premise AD/LDAP synchronization by following the dedicated documentation.