Directory Services
Directory Services allows you to integrate your PBX with external identity providers for automated user provisioning and synchronization. Three providers are supported:
- Azure Active Directory (Microsoft Entra ID) — via OAuth2 and Microsoft Graph API
- Okta — via OAuth2 and Okta Users API
- LDAP / Active Directory — via standard LDAP protocol
To configure a directory service integration, navigate to Integrations > Directory Services and click Create Directory Service Integration.
Select the Directory Service Provider from the dropdown. The form will show the configuration fields appropriate for the selected provider.
Azure Active Directory (Microsoft)
Microsoft Configuration
Register the application in Azure Active Directory as described in the Microsoft documentation: https://learn.microsoft.com/en-us/power-apps/developer/data-platform/walkthrough-register-app-azure-active-directory
Requirements for setting up application registration:
- Supported account types should be set as: “Accounts in any organizational directory (Any Azure AD directory - Multitenant)”
- Application platform must be set as Web
- Redirect URI must be set to
https://YOUR_PBX_FQDN/service/oauth2/microsoft/callback(replace YOUR_PBX_FQDN with your real FQDN) - Implicit grant flows and hybrid flows should be set as: “Access tokens (used for implicit flows)” and “ID tokens (used for implicit and hybrid flows)”
A new Client secret should be created in the “Certificates & secrets” menu (note and save the value of the Client secret in notepad as this value will only be shown once).
Please make sure that you save the Client ID and Client Secret once they are provided by Microsoft — you will need them when configuring Azure Active Directory integration in Thirdlane.
The following delegated permissions must be granted (followed by the “Grant admin consent” action) from the API permissions menu:
- offline_access
- User.Read
- User.Read.all
- Directory.Read.all
Thirdlane Configuration
| Field | Description |
|---|---|
| Client ID | The Application (client) ID from your Azure app registration |
| Client Secret | The client secret value created in Certificates & secrets |
Once saved, click the authentication icon (person) to authenticate as a user with read access to Azure AD. When authentication is completed, refresh the screen — a green indicator confirms success.
Note that there is a delay between information changes in Azure Active Directory and those changes being available for synchronization.
Okta
Okta Configuration
Create a new application integration in the Okta Admin Console:
- Navigate to Applications > Applications and click Create App Integration
- Select OIDC - OpenID Connect as the sign-in method and Web Application as the application type
- Set the Sign-in redirect URI to
https://YOUR_PBX_FQDN/service/oauth2/okta/callback - Under Assignments, choose the appropriate access policy for your users
Note your Client ID and Client Secret from the application settings page.
Thirdlane Configuration
| Field | Description |
|---|---|
| Okta Domain | Your Okta organization domain (e.g., yourcompany.okta.com) |
| Client ID | The Client ID from your Okta application |
| Client Secret | The Client Secret from your Okta application |
Required user profile fields in Okta for synchronization:
- First name
- Last name
- Work phone (used as the extension number)
LDAP / Active Directory
LDAP integration connects directly to any LDAP-compatible directory (OpenLDAP, Microsoft Active Directory, FreeIPA, authentik LDAP Outpost, etc.) using standard LDAP bind and search operations.
Thirdlane Configuration
Connection Settings
| Field | Description |
|---|---|
| LDAP Server | Hostname or IP address of your LDAP server |
| Port | LDAP port (default: 389 for LDAP/STARTTLS, 636 for LDAPS) |
| Security | None (unencrypted), STARTTLS (upgrade to TLS on port 389), or LDAPS (SSL on port 636) |
| Bind DN | The distinguished name used to authenticate to the LDAP server (e.g., cn=service,ou=svcaccts,dc=example,dc=com) |
| Bind Password | Password for the Bind DN account |
| Base DN | The search base for finding users (e.g., dc=example,dc=com) |
| Search Filter | LDAP filter to identify user entries (see table below) |
Attribute Mapping
These fields control which LDAP attributes are mapped to PBX extension fields. Defaults work for most standard LDAP directories:
| PBX Field | Default Attribute | Active Directory | Description |
|---|---|---|---|
| Extension | telephoneNumber | ipPhone or custom | Used as the extension number |
| First Name | givenName | givenName | User’s first name |
| Last Name | sn | sn | User’s last name |
mail | mail | User’s email address | |
| Mobile | mobile | mobile | User’s mobile number |
| Unique ID | entryUUID | objectGUID | Tracks users across syncs |
The Unique ID attribute is critical for tracking users between syncs. If the attribute is not present on an entry, the system falls back to the entry’s DN (Distinguished Name).
Recommended Search Filters
| Directory Type | Recommended Filter |
|---|---|
| OpenLDAP | (objectClass=inetOrgPerson) |
| Active Directory | (objectClass=user) |
| FreeIPA | (objectClass=inetOrgPerson) |
| authentik LDAP Outpost | (objectClass=inetOrgPerson) |
Test Connection
After entering the LDAP settings, use the Test Connection button to verify connectivity. The test will:
- Connect to the LDAP server on the specified port
- Perform a bind with the provided credentials
- Execute a search with the configured filter
- Report the number of users found
The Test Connection button is available before saving — you can verify settings work before committing them.
What Happens After Configuration
After configuring any directory service provider, you need to perform an initial Directory Sync to import users into the PBX. Subsequent syncs can be triggered manually or run automatically on an hourly schedule.