Connect an on-premises Active Directory (AD) server as an inbound identity provider (IdP). After binding, IDaaS synchronizes AD organizations and accounts into its directory, and users can log on to IDaaS and downstream applications using their AD credentials.
How it works
IDaaS acts as a cloud-hosted identity hub. An inbound AD binding creates a one-way trust: IDaaS reaches out to your AD server using its outbound IP address to read organizational data and authenticate users. Using the network endpoint feature, IDaaS can reach AD without opening public internet ports.
The overall process has three steps:
Connect to AD — configure the server address, credentials, and network endpoint.
Select a scenario — enable synchronization, delegated authentication, or both.
Configure field mapping — map AD fields to IDaaS account fields, and optionally attach AD users to existing IDaaS accounts.
Prerequisites
Before you begin, ensure that you have:
An IDaaS instance
An AD administrator account with at least read permissions
(Recommended) StartTLS or LDAPS configured on your AD server to encrypt the LDAP connection. See AD security configuration
Connect to AD
Step 1: Connect to AD
Log on to the IDaaS console. Select the target instance and click Console in the Actions column.IDaaS console
Click IdPs > Inbound > Add Inbound, find AD in the list, and then click Add.
In the Connect to AD panel, configure the following parameters.
Parameter Description Display name The name shown to users when they log on to and use IDaaS. Network access endpoint Controls how IDaaS reaches your AD server. A shared endpoint provides a shared, fixed public outbound IP address. A dedicated endpoint provides a dedicated private outbound IP address and a public outbound IP address, and can access your Alibaba Cloud Virtual Private Cloud (VPC) over a private network — no public port required. Add the outbound IP address of the IDaaS instance to the IP whitelist of your AD server. For details, see Network endpoints. Server address Address of the AD server. AD uses port 389 by default, for example, 127.0.0.1:389. Use port 636 when Lightweight Directory Access Protocol over SSL (LDAPS) or StartTLS is enabled.Enable StartTLS Encrypts the LDAP connection. Strongly recommended. See AD security configuration. Administrator account The AD account IDaaS uses to read AD data for synchronization or delegated authentication. Must have at least read permissions. Supported formats: User Principal Name (UPN, for example, example@example.com) and Distinguished Name (DN, for example,cn=admin,ou=Technical Department,dc=example,dc=com).Administrator password The logon password for the administrator account. 
Step 2: Select a scenario
Select the features to enable for this AD connection.
Feature descriptions
| Feature | Description |
|---|---|
| Synchronization direction | Imports user and organization data from the configured AD source node into IDaaS. Set Source node to the DN of the AD node to synchronize. Root node format: dc=example,dc=com, where example.com is your domain. |
| Incremental synchronization | Listens for changes in AD and runs a synchronization task approximately every 10 minutes. The first incremental synchronization automatically performs a full synchronization. If a large volume of data is changed in a single incremental synchronization, processing may be delayed — run a full synchronization periodically to ensure data consistency. If a single account fails to import, other records are unaffected. View failure details in Synchronization logs. Enable the AD Recycle Bin on your AD server to receive deletion events. |
| Delegated authentication | Lets users log on to IDaaS using their AD username and password. |
| Automatic password update | When a user logs on via delegated authentication and the IDaaS account has no password, IDaaS updates it with the user's AD password. The AD password must meet the IDaaS password policy; otherwise, the update is skipped. |
Advanced settings
User or organization ObjectClass: Defines whether an object in the AD query results is treated as a user or an organization. For example, objects with
ObjectClass=userare treated as users. The default value is correct for most AD deployments.User logon identity: The AD properties IDaaS uses to look up a user during delegated authentication. Separate multiple properties with a comma to create an OR relationship — a user can log on with any of the specified properties. Make sure that each property uniquely identifies the same AD user; otherwise, delegated authentication fails.
User filtering: A custom
filterstatement that limits which AD users are synchronized. Only users matching the filter are imported. By default, the filter includes anObjectClasscondition combined with other conditions using AND. Click View details to see the full statement. See Filter syntax for details.WarningChanges to
filteraffect full synchronizations. During a full synchronization, IDaaS accounts and organizations that no longer meet the filter conditions are deleted. Adjust the synchronization protection limit and test the new filter thoroughly before applying it in production.
Step 3: Configure field mapping
Configure field mapping to attach AD users or organizations to existing IDaaS accounts or organizations, or to use AD field values as IDaaS account data. For example, use an AD user's phone number as the IDaaS username.
To use the mapping identifier, manually enable it for each field where you want matching behavior — for example, the mobile phone field.
The mapping identifier works as follows: IDaaS matches the configured AD field against the corresponding IDaaS account field. If a match is found, the AD data is attached to the existing IDaaS account and the IDaaS account is overwritten with updates. Otherwise, a new IDaaS account is created.
For details, see Field mappings.
AD security configuration
By default, LDAP data is transmitted in plaintext, creating a risk of interception. LDAPS or StartTLS significantly improves transmission security. Configure a certificate in AD, then enable LDAPS or StartTLS in IDaaS.
In Server configuration, install the required role, promote the server to a domain controller, and add a certificate. Use SHA256 as the signature algorithm.
After the certificate is configured, obtain the certificate fingerprint in IDaaS with a single click. This establishes a trust relationship between IDaaS and the AD certificate and reduces the risk of forged certificates.
To verify that the certificate fingerprint shown in AD matches the one in IDaaS, run:
openssl s_client -connect server_host:port | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256AD custom configuration
ObjectClass
In AD, ObjectClass is a collection of attributes assigned to every object. It defines whether an object is a user, an organization, or a computer. For example, find a user with the filter objectclass=person or objectclass=user. To view an object's ObjectClass, open Properties for that AD object.
Logon identity
When a user logs on to IDaaS using AD delegated authentication, IDaaS uses the configured logon identity properties to look up the user in AD and verify the password. Commonly used properties include userPrincipalName, sAMAccountName, phone number, mailbox, and employee ID. Define these properties when creating the identity provider or in the Delegated authentication settings. When multiple properties are configured, make sure they are unique and correspond to the same AD user; otherwise, delegated authentication fails.
Filter
Changes to ObjectClass and filter affect AD filter conditions. During a full synchronization, IDaaS accounts and organizations that do not meet the updated filter conditions are deleted. Adjust the synchronization protection limit and fully test filter changes — for example, in a separate IDaaS instance — before applying them to production.
Introduction
To synchronize only specific users from AD to IDaaS, define a custom filter statement. Only users meeting the filter conditions are synchronized. By default, the filter includes an ObjectClass condition combined with AND. Click View details to see the complete statement.
Common syntax
| Operator | Meaning | Example |
|---|---|---|
= | Equal to | (cn=Alice) |
>= | Greater than or equal to | (pwdLastSet>=1319563845000000000) |
<= | Less than or equal to | (sAMAccountName<=a) |
& | AND — all conditions must be met | (&(cn=CN*)(memberOf=cn=Test,ou=HQ,dc=Domain,dc=com)) |
| | OR — any condition must be met | (|(cn=Test*)(cn=Admin*)) |
! | NOT — none of the conditions must be met | (!(memberOf=cn=Test,ou=HQ,dc=Domain,dc=com)) |
Common statements
| Scenario | Filter example |
|---|---|
| Username starts with "CN" | (cn=CN*) |
| User with a specific mailbox | (|(proxyAddresses=*:alice@example.com)(mail=alice@example.com)) |
| User in a specific group | (memberOf=cn=Test,ou=HQ,dc=Domain,dc=com) |
AD synchronization configuration
Base DN
The Base DN is the path identifier for a node in AD. IDaaS performs queries and data synchronization only within this node's scope. Set the Base DN in the Synchronization direction settings.
DN format: ou=Some Organization,dc=example,dc=com. The root node format is typically dc=example,dc=com, where example.com is your domain. View the DN of any node directly in the AD Administrative Center.
Node fingerprinting: When you set the Base DN, IDaaS records the node's ObjectGuid as a unique fingerprint. If the Base DN path changes later — for example, if you delete and recreate an organizational unit with the same name — the new node has a different ObjectGuid. Because the stored fingerprint no longer matches, IDaaS blocks synchronization until you reconfigure the source node. This prevents accidental data sync to the wrong node after AD reorganization.
Incremental synchronization
When user or organization data changes in IDaaS, IDaaS pushes the changed data to AD if the data falls within the scope of the configured source node.