Roster for LDAP and Active Directory

Bring directory-backed participant resolution to LDAP-compatible environments.

Roster connects to LDAP-compatible directories—including Active Directory over LDAP or LDAPS—to resolve who should approve, own, review, receive, or handle work. Use your existing directory schema while keeping deployment, credentials, field mappings, and data flow under your control.

Connect LDAP or Active Directory Read the configuration guide

Last verified 07/13/2026

Use your existing directory without rebuilding your organizational model.

Many organizations maintain users, groups, and organizational structure in Active Directory or another LDAP-compatible directory.

Agents and workflows still need to translate those records into business responsibility:

“Which users are in this DN?”

It asks:

“Who owns this system?”

“Which group should approve the change?”

“Who handles this operational escalation?”

“Who is covering while the normal owner is unavailable?”

Roster maps selected LDAP users and groups to project-specific participants, then resolves who should act using directory membership, metadata, and delegation context.

How Roster connects

Roster supports LDAP v3 operations over LDAP or encrypted LDAPS.

Typical connector operations include bind, search users, search groups, and read group members.

Field mappings align your directory attributes with Roster's normalized user and group model.

Selected records are materialized in Roster. Scheduled refresh updates the selected records and attached membership relationships used by participant resolution.

What you can resolve

Approval responsibility from an AD group

Bind a Roster participant to the CN=Production-Approvers group instead of hard-coding an approver email.

“Who should approve this firewall change?”

Application or infrastructure ownership

Map an LDAP group to a participant representing technical or business ownership.

“Which group owns the manufacturing application?”

Release and deployment sign-off

Route production sign-off to the current members of a change-control group.

“Who signs off on this production deployment?”

Incident and operational escalation

Resolve the correct on-call or escalation group for a service, region, or severity level.

“Who is the network on-call for this region?”

Delegated coverage

Apply time-bound Roster delegations without changing LDAP membership.

“Who is the active delegate for the infrastructure reviewer?”

From an LDAP group to a participant

The LDAP group supplies direct membership. The Roster participant supplies the workflow meaning and project boundary.

The same LDAP group can support different workflow responsibilities in different Roster projects without changing the source directory.

Participants carry metadata such as: Region, Environment, Change class, Application, Severity, Escalation level.

Use LDAP context from every Roster surface

Once directory records back Roster participants, the same context is available across every Roster surface—including from inside a private network.

MCP

Let an MCP-compatible AI client resolve ownership from directory data.

claude · mcp

› Who should approve the Atlas firewall change?

→ tool: resolve

↳ Priya Shah · Production Release Approver · via Production-Approvers

REST API

Add directory-backed resolution to internal apps and workflow engines.

POST /api/v1/resolve

curl -X POST "<your-roster-public-url>/api/v1/resolve" \

  -H "Authorization: Bearer $ROSTER_API_KEY" \

  -H "Content-Type: application/json" \

  -d '{"query":"Who approves firewall changes?","project_id":"proj_atlas"}'

// 200 OK

↳ { "participant": "production_release_approver", "user": "priya@acme.com" }

CLI and CI

Resolve sign-off from a private-network pipeline or terminal.

~/roster · zsh

$ roster resolve "Who approves this network change?"

↳ ✓ Priya Shah  <priya@acme.com>

  role: Production Release Approver · source: ldap:Production-Approvers

Roster platform

Administrators map DNs to participants and manage delegations, mappings, and TLS trust.

app.roster.ai › participants

• Production Release Approver

• linked · ldap:CN=Production-Approvers

• delegation · Priya S. → Mark J. (until Fri)

What Roster reads

LDAP data	Used by Roster	Materialized in Roster
Stable user identifier	Yes	For selected users
Username	When mapped	For selected users
Primary email	When mapped	For selected users
Display name	Yes	For selected users
Stable group identifier	Yes	For selected groups
Group name	Yes	For selected groups
Group email	When mapped	For selected groups
Direct group members	Yes	For selected groups
Password hashes	No	No
Authentication credentials	No	No

Roster field mappings let you align source attributes such as:

uid
sAMAccountName
userPrincipalName
mail
displayName
cn
member
uniqueMember
objectGUID
entryUUID

with normalized Roster fields such as:

external_id
user_name
primary_email
display_name

Use a stable, immutable attribute for external_id. Avoid using a display name as the provider key.

Roster uses the configured bind credential to read the directory. It does not retrieve user passwords.

Live lookup and materialized resolution

Roster uses two deliberate data-access modes.

Live provider browsing

Administrators search LDAP live from the Roster participant picker when selecting users or groups.

Materialized runtime resolution

Runtime resolution, REST search, and MCP search use Roster's materialized state, giving every integration surface a consistent dataset even in constrained network paths.

Connection requirements

You need:

01An LDAP or LDAPS endpoint reachable from Roster
02A read-only bind identity
03A bind password or certificate-based credential as applicable
04User and group search bases
05User and group search filters
06Membership configuration
07Field mappings
08TLS trust configuration for LDAPS
09Provider-secret encryption enabled in Roster

Use encrypted transport:

ldaps://directory.example.com

Configure Roster provider-secret encryption before storing credentials:

ROSTER_PROVIDER_SECRET_ENCRYPTION_KEY=<generated-key>
ROSTER_PROVIDER_SECRET_KEY_ID=env:prod-2026-07

Supported secret material can include:

bind_password
certificate
private_key

Prefer a bind identity with read access only to the directory objects and attributes Roster requires.

View detailed LDAP connector requirements

LDAP, Active Directory, and Entra ID

Use the connector that matches your source of truth and network architecture.

LDAP / Active Directory connector

Appropriate when AD is reachable via LDAP or LDAPS, Roster runs inside or connected to the private network, custom search bases and attribute mappings are required, or cloud APIs are not the preferred path.

Microsoft Entra ID connector

Appropriate when Microsoft Graph is the directory integration surface, users and groups are maintained in the Entra tenant, or the Roster deployment can access Microsoft Graph.

These are separate connectors. An organization may use one or both.

Example: resolve an infrastructure approver

A private-cloud automation is preparing a network change.

It asks:

“Who should approve this production firewall change?”

Roster evaluates:

The infrastructure project
The Network Change Approver participant
Associated LDAP users or groups
Current materialized group membership
Relevant participant metadata
Active Roster delegations

The automation receives the active participant and continues through the existing change-management process.

Frequently asked questions

Yes, when Active Directory is accessed through LDAP or LDAPS.

Add participant resolution to your private directory environment

Keep identities and groups in LDAP or Active Directory. Use Roster to turn them into project-specific answers about who should act.

Connect LDAP or Active Directory Read the LDAP connector documentation Explore all integrations