Overview & Concepts

Building a Unified IAM Infrastructure

In large organizations, consolidating Identity & Access Management (IAM) platforms from different vendors and locations is seldom realistic. Corporate groups that grow through acquisition typically inherit a patchwork of directory systems—some modern, some decidedly legacy. Big‑bang consolidation projects are long, costly, and rarely deliver on expectations.

RCDevs tackles the issue with a federated strategy: instead of forcing a rip‑and‑replace, WebADM unifies all those disparate IAMs behind a single meta‑IAM layer. That layer exposes standard interfaces—LDAP, REST, OpenID Connect, SAML, RADIUS—so applications (cloud or on‑prem) can consume identities without caring where they reside.

A typical scenario could involve a parent company on Okta, a few subsidiaries on classic Active Directory (AD), and other branches on assorted LDAPs. WebADM federates them all, lets security teams write uniform access policies, and keeps credential management simple—no IdP chaining, no password sprawl.

WebADM and External IAM Integration

Since WebADM 2.3.20, administrators have been able to import users and groups from an external IAM into WebADM’s own LDAP tree. The first incarnation was one‑way (remote → WebADM).
Starting with WebADM 2.4.6, the platform gained two‑way capabilities for major cloud providers (Okta, Duo, PingOne, OneLogin, Google Workspace) and for Active Directory via the new LDAP Connector.

Key capabilities shared with the cloud connectors:

  • Create, delete, rename, copy, move and update users & groups on either side.
  • Real‑time propagation of local changes.
  • Cross‑IAM object moves (for example, from AD to Okta) that feel like native LDAP operations.
  • Preservation of group structures and memberships during moves.
  • “auto-destruction date” feature to auto‑delete a synced object.
  • Optional password copy during user moves for friction‑free onboarding.

These functions let WebADM act as both single‑pane‑of‑glass and single control plane for identity lifecycle, greatly simplifying merger‑and‑acquisition work.

LDAP Connector for Active Directory (available from WebADM 2.4.6)

The LDAP Connector is a pull‑based synchronisation engine dedicated to Active Directory. WebADM binds to one or more AD Domain Controllers (ADDCs), reads objects (users & groups) and mirrors them into its own directory.

Important: The LDAP Connector is not the default or recommended approach for standard AD integrations. RCDevs still advises configuring AD in read/write mode.

The connector is designed for two main use-cases:

  1. MSSP / MSP environments where WebADM needs to validate user passwords against multiple customer Active Directories without installing any software on those domain controllers.
  2. Deployments where standard password-sync is too slow. When a user changes their AD password, WebADM / OpenOTP may still validate the old LDAP password until the next AD sync, causing temporary authentication failures. The connector removes this gap by forwarding the password directly to AD in real time.

How It Works

  1. WebADM opens an LDAPS connection (port 636) to each configured ADDC.
  2. During each sync cycle, the connector retrieves all user objects located under the User Search Base configured in the WebADM domain settings, and likewise pulls all group objects under the Group Search Base.
  3. New, modified and removed records are reflected in WebADM.
  4. When TwoWay is enabled and the bind DN has write rights, WebADM can push back local edits to AD. Refer to the attribute mapping section to see which attributes can be edited in AD and reflected in WebADM, and vice versa.

Configuration Steps

Create a Container in WebADM

  1. Sign in to the WebADM Admin Portal with a super_admin account.
  2. Navigate to Create ➜ Organization / OU and choose where the AD‑imported objects will live (e.g., External Providers/Active Directory).
Create Organization object
Create Organization object creation
Organization object creation

  1. Object placement logic:

    • The connector does not create any OUs or containers by itself—every synced user and group lands flat under the Search Base you provide.
    • If you enable Subdir, WebADM will automatically build a per‑department tree beneath that base (one OU/container per unique department value found in AD).

  2. For this example, we created two OUs named Users and Groups, which will respectively host synced users and groups.

Create the WebADM User Domain

  1. Go to Admin ➜ User Domains ➜ Add Domain.
  2. Enter a name (e.g.,rcdevssupport.com) and optional description. Click Proceed and then Create Object.
WebADM Domain object creation

  1. Fill User Search Base and Group Search Base with the DN of the container chosen above.

  2. UPN Mode: In this configuration, the UPN mode must be set to Implicit, not Explicit, and the UPN Suffix must match the Active Directory UPN suffix to allow authentication using both DOMAIN\SAMAccountName and the constructed UserPrincipalName.

Domain configuration options

  1. Navigate to Directory Synchronization settings:

    • Provider → AD.
    • Tenant ID → LDAP connection URI and tree base like ldaps://adserver/DC=MyOrg,DC=com. Port will be the 636 (LDAPS). In this example, ldaps://192.168.4.2/DC=rcdevssupport,DC=com
    • Client ID → Active Directory proxy user DN or UPN with related permissions. Permissions depends on attributs manipulated from the WebADM framework.
    • Secret Key → Active Directory proxy user password.
    • User Password Mode → Remote (validate via LDAP bind) or Local (validate against WebADM’s hash).
    • Toggle PwSync, PwCopy, TwoWay, Active, Subdir as required (see table below).
    • Sync Period → default 1 hour
Synchronization options
  1. Hit Apply, then in Registered LDAP Domains click Sync Now for the first import.
Domain object configured

The directory is now synced.

AD Synced

Sync‑Option Cheat‑Sheet

Option What it does Remarks & Caveats
PwSync Keeps AD and WebADM passwords identical after authentication. Works only after a successful password check. Direction depends on User Password Mode. Daily push in Local mode happens at first login after 00:00 server time.
PwCopy Lets you copy / move users between domains without forcing a reset. WebADM stores a secure, encrypted copy of the password in its sync cache just long enough to recreate it.
TwoWay Pushes attribute / membership edits made in WebADM back to AD. The bind account must have the necessary write ACLs.
Active Activates newly imported users or groups at the end of the sync. Activating a user consumes an OpenOTP licence; activating a group enables WebADM group‑policy evaluation.
Subdir Builds department‑based sub‑folders under the User Search Base. Perfect for large tenants: HR updates department in AD → user is moved to the matching OU automatically.

Attribute Mapping

All attributes below are bi‑directional when TwoWay is enabled.

WebADM Attribute(s) Active Directory Attribute Direction Notes
uid sAMAccountName ← → Login name when UPN Mode = Implicit
uid userPrincipalName ← → Present only when UPN Mode = Explicit
sn sn ← → Surname
givenName givenName ← → First name
description description ← →
title title ← → Job title
l (locality / city) l ← →
s s ← → Rarely used; kept for compatibility
c (country code) c ← → Two‑letter ISO‑3166 country code
o (organisation / company) o ← →
st (state / province) st ← →
street street† ← → Alias of streetAddress in AD
postalCode postalCode ← →
any attribute in mail_attrs mail ← → Default: ['mail']
any attribute in mobile_attrs mobile ← → Default: ['mobile', 'mobilePhone']
any attribute in language_attrs preferredLanguage ← →
password Refer to PwSync feature ← → Password hashes never leave AD
lockout logonHours / ACL flags ← → Account lock managed via logonHours control

Group Synchronisation

One‑Way Sync (Default)

  • Group structures and memberships are imported from Active Directory (AD) into WebADM.
  • Synced groups in WebADM are read-only; any manual changes are automatically overwritten during the next synchronization.
  • Only direct group memberships are synchronized (member attribute).
  • Nested groups are supported via the member attribute.
  • The memberOf attribute is calculated by AD and is not writable; RCDevs Directory/OpenLDAP uses the same mechanism.
  • If you require custom group configurations, you can create local groups within WebADM and manually assign imported users.

Two‑Way Sync

  • Groups can be created, renamed, or deleted directly in WebADM, and these changes are pushed back to AD.
  • When creating a new group, WebADM prompts: “Local object only?”
    • Select Yes to keep the group local (not synced to AD).
    • Select No to enable synchronization, making the group editable in both WebADM and AD.

Visual Indicators in WebADM

  • Green objects → synced with an external IAM (AD via LDAP Connector).
  • Red objects → local only.

With Two‑Way mode enabled, you can set an auto‑deletion date (under LDAP Actions) for any user. On that date the account is removed from both WebADM and Active Directory.