Skip to main content

Connecting Active Directory or a generic LDAP directory

A read-only bind-and-search directory pull over LDAPS or StartTLS, with Active Directory's own attribute conventions as the default.

Written for whoever runs IT8 min readUpdated

This connector reads users and groups directly from Active Directory, or any other LDAPv3 directory, over a bind-and-search connection — no agent to install, unlike the AD agent used for PAM discovery and delegated authentication. It is read-only: nothing is written back to your directory.

Create a read-only bind account

Create a dedicated account in your directory with read access to the users and groups you want synced — do not reuse a personal or highly privileged account. You will need its distinguished name (DN), its password, and the base DN to search from (for example, DC=example,DC=com, or an organizational unit further down the tree if you want to limit the scope).

Connecting it

  1. Open the catalogue entry

    Under Integrations → Catalog → Active Directory / LDAP, choose Directory sync.

  2. Enter the host and choose a transport

    Enter the directory server's host and port (defaults to 636 for LDAPS, 389 for StartTLS unless you set a different port), and choose LDAPS or StartTLS. Enter the bind DN, bind password and base DN.

  3. Leave the attribute and filter fields on their defaults for Active Directory, or override them

    The defaults assume Active Directory's own conventions. For a different LDAPv3 directory, override the fields below.

  4. Test and save, then run the first sync

    Test performs a real bind and a bounded search before anything is stored. Save, then press Sync now for the first pull; after that it runs on the same schedule as the other directory connectors.

Default attribute and filter conventions

The Active Directory defaults this connector assumes, all overridable for a generic LDAPv3 directory.
SettingDefault
Username attributesAMAccountName
Principal name attributeuserPrincipalName
User filter(&(objectClass=user)(objectCategory=person))
Group filter(objectClass=group)

For a directory that is not Active Directory (an OpenLDAP or other generic LDAPv3 server), override each of these to match your schema — there is no assumption baked in beyond what the fields above default to.

How active/inactive status is read

On Active Directory, an account's active status is read from the userAccountControl attribute's ACCOUNTDISABLE bit — a disabled AD account comes into Qorionix as inactive. A directory with no userAccountControl attribute at all (any non-AD LDAPv3 directory) has every synced account default to active, since there is nothing to read a disabled state from.

Was this article wrong?

If a procedure here does not match what you see, or a limit we described has changed, tell us and we will fix the page. Email us about this article, or see how to get help if you need an answer rather than a correction.

Everything in integrations and notifications