Overview
All the WebADM web application or services identify a user with a username, a password and a domain name. The domain objects establish the relationship between a domain name and an LDAP tree base.
Also, when an application wants to obtain an LDAP user DN corresponding to the provided login information, it will use the domain tree base to build the LDAP search. All Domains objects must be stored in the same container (as specified in the WebADM main configuration file) to be read by WebADM at start-up.
Domain objects are required to locate any user or group within the defined search base. A user not associated with any domain will not be recognized by WebADM. Additionally, a licensed (activated) user not associated with any domain will not be included in the license count. The license count is performed per domain by the WebADM background jobs.
Create Domain object
Log in to the WebADM Administrator portal and click on the Admin tab, then select the User Domain box. Note that a default domain has already been created during the WebADM graphical setup wizard.
On the next page, click the Add Domain button. Enter a Common Name for your domain object, optionally provide a Description, and then click Proceed.
Click on Create Object.
The domain object has been created. You can now configure it through the Domain Configurator Editor.
Domain Configuration and settings
A WebADM Domain object supports the following default settings:
-
User Search Base: The tree base corresponding to the domain and to be used in the user LDAP searches. -
Group Search Base: The tree base to be used in the LDAP group searches. If not specified, it defaults to the Tree DN. This setting will be ignored if WebADM is configured to use direct groups only. -
UPN Suffix:ExplicitUPNs are configured via the userPrincipalName attribute in ActiveDirectory.Implicitassumes UPN names built with username@suffix (works with any LDAP).
-
Domain Name Aliases: A comma-separated list of aliases for the Domain name. Setting multiple names for a single Domain can be useful in the following scenarios:- You want to enable both ActiveDirectory, NetBIOS and DNS domains naming for your integrations (ex. MYCOMPANY and mycompany.com).
- You use ActiveDirectory User Principal Names (UPNs). In this case, you can create a Domain alias corresponding to the users’ UPN suffix.
- Using local accounts with Windows login integrations and with computers out of AD domain. The workgroup or computer name value can be configured in that setting in order to match that domain during authentications.
If a domain value received is not recognized by any WebADM domain object, the request will fail. However, if the domain is enforced at the client policy level and the request is made with an empty domain, the request will be accepted. In this case, user lookup will occur in the domain specified by the client policy object.
Brute Force Protection: When enabled, it prefetches and caches all domain DNs for 5 minutes after 25 unresolved user attempts within 10 seconds. This mitigates brute force attacks on public endpoints that can overload LDAP backends used with WebADM by triggering excessive LDAP search operations.
Directory Synchronization
Starting with WebADM version 2.3.19, a sub-framework has been implemented within WebADM domain objects to synchronize and federate identities from cloud providers like EntraID, OKTA, SalesPoint, OneLogin and more. During synchronization, the system will create objects in the User and Group search bases if they do not already exist, and it will modify existing objects if any changes have occurred in the source object. Once objects are synced and created into the LDAP directory used with WebADM, accounts are usable with all RCDevs integrations.
-
Sync Type: When enabled, the domain user/group search base contents will be populated with EntraID/Okta identities and groups.
Warning: Any existing user or group will be replaced by the remote EntraID/Okta objects. -
Tenant ID: This setting is specific to your provider. The Tenant ID is required to inform WebADM from which tenant the information should be retrieved. -
Client ID: The unique identifier for your application registered in Microsoft EntraID. It is used to authenticate and authorize WebADM to interact with the EntraID services on behalf of your tenant. -
Secret Key: EntraID Client Secret or Okta API Key. -
Activate New Users: When this setting is enabled, all synced user objects will be automatically licensed and activated. -
Sync User Password: When this setting is enabled, the remote password will be also synced in order to be used with other integration. Local LDAP password is automatically updated after a EntraID success password check. When enabled WebADM will fallback to the local LDAP check if EntraID is unaccessible.
Once your synchronization configuration is complete, return to the Domain menu and click the Sync Now button to synchronize your cloud provider.
External EntraID accounts are ignored during sync operations. If an account is removed from EntraID, it will also be removed from WebADM. After the initial synchronization, subsequent sync operations will be automatically managed by WebADM Background Jobs.
Below, an Okta syncrhonization configuration example:
A WebADM Domain object supports the following User Access Policy settings:
Allowed Groups: Mandatory LDAP group(s) the domain users must belong to (in order to be considered as part of the domain). If set, users must be a member of at least one of the listed groups.
Excluded Groups: Exclusion LDAP group(s) the domain users must not belong to. If set, users must not be a member of the listed groups.Allowed Addresses: Required network address(es) with netmask the domain must be accessed from. If set, users must be located in at least one of the listed networks (ex. 192.168.1.0/24).Excluded Addresses: Excluded network address(es) with netmask the domain must not be accessed from. If set, users must not be located in any of the listed networks.Allowed Locations: Required country code(s) the domain must be accessed from. If set, users must be located in at least one of the listed countries.Excluded Locations: Excluded country code(s) the domain must not be accessed from. If set, users must not be located in any of the listed countries.Allowed Hours: If set, the domain can be used only during the specified week hours.Excluded Hours: If set, the domain cannot be used during the specified week hours.
A WebADM Domain object also supports Application Access Policy through a setting named Allowed Applications. If this setting is not defined, all WebADM applications and services are allowed by default for users within the domain.
Click Apply to save you domain configuration.
Domain fallback
A domain fallback can be created for specific use cases. A domain fallback must be named the same as the default domain but with a # at the beginning of the object name.
For example, if you have a domain named rcdevsdocs, you can create a fallback domain by naming it #rcdevsdocs. This configuration ensures that if a user is not found in the rcdevsdocs domain, the system will automatically search in the #rcdevsdocs fallback domain.
Be aware that this setup may have side effects. For instance, if a user with the same username exists in both domains, the fallback will not occur; the fallback domain will only be used if the user is not found in the primary domain. A fallback domain can be useful with a mount point, for example, if you want to keep external and internal identities separate within your main LDAP infrastructure and your client application forwarding the request is not able to provide different domain values.
Here you can see that WebADM see the other domain has a fallback.
Renaming the default domain object
If you rename the default domain object created during the WebADM setup wizard, you will need to reconfigure the default domain for the various applications and services or add the default value to the Domain Name Alias setting.