Skip to main content

Microsoft Active Directory

The Omada Microsoft Active Directory connector utilizes the Microsoft Active Directory DirSync Control. See Polling for Changes Using the DirSync Control for details. This technology allows the connector to perform real delta import where only changes since the last import are handled, compared to the old connector that imported the entire directory and then calculated the delta.

important

Omada Microsoft Active Directory is configured to perform imports in delta mode by default. Perform full imports on regular basis, for example once a week as good practice. These full imports allow the Microsoft Active Directory connector to retrieve changes that are kept by Active Directory for only a specified time or, for example, changes to Organization structure of the AD identity.

The connector supports the following actions:

  • Onboarding any number of entire Active Directory domains or their parts
  • Importing information about Users, Computers, Groups, nested groups, group ownerships, and group memberships on internal and external domains
  • Automating the provisioning and deprovisioning of Active Directory users, groups, and memberships

Supported objects and operations​

The Active Directory connector allows managing access rights. Each Active Directory Domain must be onboarded as a separate system in Omada.

ObjectPossible operations
UsersCreate, read, update, delete
User passwordsCreate, update
Computers (as Accounts)Read
GroupsCreate, Read, update, delete
Nested GroupsRead
Group MembershipsCreate, read, delete
Organizational UnitsCreate, read, update, delete

In order to perform those operations you must set the System category to Access rights.

Minimum required permissions​

A service account with sufficient rights in Active Directory to manage users, computers, groups, and organizational units is required. See How to Configure the ADMA Account in the Microsoft documentation to correctly configure the service account. Use the following guidelines for the configuration of this account:

  • The service account should be a regular user account.
  • To import identity data from Active Directory, you must grant "Replicating Directory Changes permission" to this account.
  • To export or provision identity data to Active Directory, you must grant full control of all organizational units to the account managed by it. Full Control permissions include create, modify, delete, and manage all objects (users, groups, computers, etc.) actions within the organizational unit. These permissions can either be given individually or using the Full Control checkbox.
info

Specific permissions depend on the design and implementation of security policies and other measures in your organization (for example, how your organization handles full control permissions with Security group access).

Implementation notes​

Omada's Microsoft Active Directory Connectivity supports nested groups and memberships across all domains in the same domain forest, as well as nested groups and memberships to external domains. Omada Identity will automatically resolve group memberships for user accounts from trusted domains (foreign security principals), provided all the domains are onboarded into the same system category.

For Active Directory domains onboarded into Omada Identity in separate system categories, define trusts between the domains (systems) in Omada Identity to represent group memberships for foreign security principals. Only one-way trusts are supported in Omada Identity between systems in different system categories.

Omada Identity supports requesting and provisioning group memberships for an account belonging to a different domain in which the group resides. To enable this scenario, you must configure which other Active Directory domain (system) is trusted by the specific domain - according to the trust relationships already defined in your Active Directory infrastructure.

Omada Identity requires that if one system trusts second system in Omada Identity, then Active Directory domain of the first system need at least incoming trust from Active Directory domain of the second system (bi-directional trust is also valid). Both domains needs to share authentication configuration, as the collector will resolve object types in the second system domain using the connection details of first system. Omada Identity checks if the system has a trust.

  • If not, an import profile for the single system is created.
  • If the system has a trust, an import profile for the entire category is created.

DirSync based resilience in Microsoft Active Directory collector​

In the Microsoft Active Directory collector, resilience is provided by a built-in Active Directory nodes replication and load balancing solution. If server nodes are configured to be replicated in Active Directory, they point to the same domain name. This domain name should be used as a server name in the LDAP path. It is only up to the Active Directory internal load balancer to decide which server/host is used for data import, and this decision should be optimal from the communication point of view. In case of a node failure, Active Directory selects the new (replicated) server, and this server is used in data import. In such a situation, there are two possibilities:

  1. If the parameter Full import in case of domain controller change from the Advanced settings task is selected, then the collector will perform full data import (not delta).

  2. If the parameter Full import in case of domain controller change from the Advanced settings task is not selected, the collector will perform delta import. This configuration is not recommended as there is a possibility that the data in this replicated controller is different than in the data origin controller.

Other scenario to consider is that data import might fail because one of the controllers might stop responding during the import of data. For such cases, users can configure Retry times and Full import in case of domain controller change and error in the Advanced settings task.

A sample import flow in case of an error in the Active Directory replicated environment may look as follows:

  1. Data import is started.
  2. Active Directory server disconnects -- communication is lost.
  3. An error in the collector is logged.
  4. Collector automatically retries import if the number of retries is configured to do so.
  5. In the meantime, Active Directory selects the new (replicated) node if one was available.
  6. The collector connects to Active Directory after failure (using the same domain name credential) and gets information that it is now connected to a different server than it was on the first time.
  7. If Full import in case of domain controller change and error is selected, the collector erases the delta cookie and performs a new import of all data (not only delta difference). This import is performed to ensure that after automatic server change, the data received are complete. If this option is not selected (not recommended), the collector will perform only delta import.
  8. Data is saved, and the collector completes its work.

This process is repeated a number of times configured by the user in the Retry times setting if an error is encountered either during opening the connection or importing data. In this solution, no manual server configuration or any connection unbinding is necessary.

important

Microsoft Active Directory doesn't support the primary group functionality. Therefore, it does not query the PrimaryGroupID attribute to build the group membership of a user. This may cause problems for users who are still using the primary group feature.

The connector offers configuration options for controlling the number of concurrent requests sent to the Active Directory domain controller. The configured number should be aligned with the number of concurrent connections allowed by the Active Directory. See MaxConnections for details.

Configuration of trusts is performed in the General settings menu in System Onboarding.

Error codes overview​

Operation type == Create
If the user already exists, a permanent error is returned.

Operation type == CreateIfNotExists
No relevant errors.

Operation type == Update
If the user is not found, a permanent error is returned.

Operation type == CreateOrUpdate
No relevant errors.

Operation type == Delete
If the user is not found, a transient error is returned.

Operation type == DeleteIfExists
No relevant errors.

Network requirements​

For the Omada Microsoft Active Directory Connectivity, the following default network ports are required to be open in firewalls.

Port numberProtocol
389LDAP
636Secure LDAP (SSL/TLS)

Other potentially useful ports to open between Omada Identity - specifically the SSIS, OPS, and ES servers - and AD:

  • TCP/UDP 135 (RPC EPMapper)
  • TCP 3268 (GC)
  • TCP 3269 (GC SSL)
  • TCP/UDP 53 (DNS)
  • TCP/UDP 88 (Kerberos)
  • TCP Dynamic (RPC)
  • TCP/UDP 464 (Kerberos Change/Set Password)
  • TCP 445 - (CIFS/ MICROSOFT-DS)

SSL requirements​

Omada recommends enabling the SSL encryption of the communication to Active Directory. In order to utilize this option, a valid certificate installed on the Domain Controller(s) and on the Omada servers where OPS and ODW resides is required. Certificates are imported in the Management Portal.

Prerequisites​

None.