Active Directory, LDAP and SSO Integration with Self-Hosted Bitrix24

Why Enterprise IT Chooses Self-Hosted Bitrix24 for Identity Integration

Self-hosted Bitrix24 stands apart from cloud CRM platforms because it gives organizations full control over authentication, enabling direct integration with Active Directory, OpenLDAP, Azure AD, or any SAML 2.0/OAuth 2.0 identity provider — eliminating password fatigue, enforcing centralized provisioning, and satisfying compliance mandates for 200+ user deployments.

Cloud CRM platforms typically lock authentication behind their own identity layer. Self-hosted (on-premise) Bitrix24 is different: because you control the server, you can plug it directly into your existing identity infrastructure — Active Directory, OpenLDAP, Azure AD, or any SAML 2.0 / OAuth 2.0-compliant identity provider.

For organizations with 200+ users, the business case is straightforward:

• Single sign-on removes password fatigue and help-desk tickets for forgotten CRM credentials.
• Centralized provisioning means new employees get Bitrix24 access the moment their AD account is created — and lose it the moment it's disabled.
• Audit trail consistency — all authentication events flow through the same identity provider logs you already monitor.
• Compliance alignment — financial, healthcare, and government organizations often mandate that all access to business systems passes through a single, auditable identity broker.

If you are still evaluating whether on-premise deployment makes sense for your organization, the self-hosted CRM data sovereignty guide covers the broader decision factors.

---

LDAP and Active Directory: How the Connection Works

Bitrix24's native LDAP module connects to any LDAP v3-compliant directory — including Microsoft Active Directory, OpenLDAP, and FreeIPA — supporting user import, attribute mapping, group sync, and incremental sync, all configurable in under five steps from the admin panel.

Bitrix24's on-premise edition ships with a native LDAP module. It connects to any LDAP v3-compliant directory — including Microsoft Active Directory, OpenLDAP, and FreeIPA.

What the LDAP module does

Capability	Details
User import	Pulls accounts from a specified OU or group into Bitrix24
Attribute mapping	Maps AD attributes (displayName, mail, department, title) to Bitrix24 profile fields
Authentication	Users log in with their domain credentials; Bitrix24 validates against LDAP
Group sync	Maps AD security groups to Bitrix24 access roles and workgroups
Incremental sync	Scheduled sync keeps accounts, names, and department assignments current

Configuration path in the admin panel

1. Navigate to Settings → System Settings → Module Settings → LDAP.
2. Enter the LDAP server address, port (389 for plain, 636 for LDAPS), and bind credentials for a service account.
3. Set the Base DN to the container you want to import (e.g., OU=Staff,DC=company,DC=local).
4. Map LDAP attributes to Bitrix24 fields.
5. Run a test connection and a trial import before enabling live sync.

Best practice: Use a dedicated read-only service account for the LDAP bind. Never use a domain admin account — if the Bitrix24 server is ever compromised, the blast radius stays limited.

Active Directory specifics

• AD uses sAMAccountName for login and userPrincipalName for email-style login. Decide which you want as the Bitrix24 login and map it consistently.
• Disable accounts in AD to immediately block Bitrix24 access on the next sync cycle — a major advantage over manual deprovisioning.
• Group-based role assignment works well for large deployments: create AD groups like B24-Managers or B24-Sales and map them to corresponding Bitrix24 roles.

---

Azure Active Directory (Entra ID) and OAuth 2.0

Organizations running Microsoft 365 can integrate Bitrix24 on-premise with Azure AD (Entra ID) via OAuth 2.0 in a seven-step app registration process, unlocking SSO and Microsoft 365 document co-editing inside the CRM, with MFA enforced entirely at the Azure Conditional Access layer.

For organizations running Microsoft 365, Azure AD (now called Microsoft Entra ID) is the natural identity provider. Bitrix24 on-premise integrates with it via OAuth 2.0, which also unlocks Microsoft 365 document co-editing inside the CRM.

App registration steps

1. Open the Azure Active Directory admin center and navigate to All Services → App Registrations → New Registration.
2. Enter an app name and select Accounts in this organizational directory only (single-tenant) or multi-tenant if you need to support guest accounts.
3. In the Redirect URI field, enter the exact callback URL shown in Bitrix24 under Settings → System Settings → Module Settings → Social Services → Office 365.
4. Under API Permissions, add: - Microsoft Graph: Files.ReadWrite.All, profile, offline_access - SharePoint: user files read/write (required for Bitrix24.Drive and Bitrix24.Docs)
5. Go to Certificates & Secrets → New Client Secret. Set a description and expiry date, then click Add. Copy the secret value immediately — it is only shown once. If you navigate away before copying, you must generate a new secret.
6. Find the Client ID on the Overview tab and copy it from there only — copying from other tabs can cause integration failures.
7. Enter the Client ID and secret in Bitrix24 under Settings → System Settings → Module Settings → Social Services → Office 365.

The optional Tenant field (e.g., yourcompany.onmicrosoft.com) restricts document editing to internal users only — useful if you want to prevent guest collaborators from editing CRM-linked files.

Note: A business Microsoft 365 account (user@company.onmicrosoft.com) is required. Personal LiveID accounts with home-tier subscriptions cannot be used for this integration.

Multi-Factor Authentication

Azure MFA can be enforced at the Azure AD level via Conditional Access policies. When a user attempts to log in to Bitrix24 via Azure AD SSO, they are challenged for the second factor by Azure — Bitrix24 itself does not need to implement MFA separately. This is the recommended architecture for organizations with a Microsoft 365 Business or higher subscription.

---

SAML 2.0 SSO: Connecting to Any Identity Provider

Self-hosted Bitrix24 acts as a SAML 2.0 Service Provider compatible with any standards-compliant Identity Provider — including Okta, OneLogin, ADFS, Keycloak, and Google Workspace — configured through a five-step metadata exchange and attribute-mapping process.

Beyond Azure AD, self-hosted Bitrix24 can act as a SAML 2.0 Service Provider (SP). This means it works with any standards-compliant Identity Provider (IdP), including:

• Okta
• OneLogin
• ADFS (Active Directory Federation Services)
• Keycloak (open-source, popular in on-premise environments)
• Google Workspace (via SAML app configuration)

Typical SAML setup flow

1. Register Bitrix24 as a SAML SP in your IdP. You'll need the Entity ID and Assertion Consumer Service (ACS) URL from Bitrix24's SAML settings page.
2. Configure the IdP to send at minimum: NameID (email), displayName, and optionally groups.
3. Download or copy the IdP's metadata XML (or the X.509 signing certificate) and upload it to Bitrix24.
4. Map IdP attributes to Bitrix24 user profile fields.
5. Test with a single user account before rolling out to the organization.

The diagram below illustrates how authentication flows across all three integration modes — LDAP/AD, Azure AD OAuth, and SAML SSO — with Bitrix24 at the center.

The following diagram shows the three identity integration paths for self-hosted Bitrix24: on-premise Active Directory via LDAP, Azure Active Directory via OAuth 2.0, and any SAML 2.0-compliant Identity Provider. All paths converge at the Bitrix24 authentication layer, which then grants access to CRM data, documents, and collaboration tools.

flowchart LR
    AD[Active Directory / OpenLDAP] -- LDAP / LDAPS --> B24[Self-Hosted Bitrix24]
    AzureAD[Azure AD / Entra ID] -- OAuth 2.0 --> B24
    IDP[SAML IdP\nOkta / ADFS / Keycloak] -- SAML 2.0 --> B24
    B24 --> CRM[CRM & Deals]
    B24 --> DOCS[Bitrix24.Drive / Docs]
    B24 --> COLLAB[Chat & Tasks]

---

Security Hardening Alongside Identity Integration

Beyond directory integration, on-premise Bitrix24 deployments most commonly fail audits on six specific gaps — including disabled 2FA, missing HSTS headers, and publicly accessible admin panels — each with a discrete remediation action that should be applied before go-live.

Connecting Bitrix24 to your directory is step one. Hardening the platform itself is equally important. Based on security audit findings from on-premise deployments, the most common gaps are:

Finding	Recommended Action
Two-factor authentication disabled	Enable 2FA for all users via the Bitrix24 OTP app — especially for admin accounts
HSTS header missing	Add Strict-Transport-Security at the web server level (nginx/Apache config) and verify HTTP→HTTPS redirect
Verbose error output enabled	Disable display_errors in php.ini and Bitrix24 config files in production
Outdated platform modules	Update Bitrix24 core and modules through the admin panel regularly
Admin panel publicly accessible	Restrict /bitrix/admin/ to a specific IP range or VPN-only access
No IP blocklist	Maintain a firewall blocklist of known attack source IPs; review weekly

Enabling the built-in web antivirus module adds an extra detection layer but does introduce some latency — benchmark your environment before enabling in production.

When SSO is active, ensure your IdP session timeout policies align with your corporate security policy. A user whose AD account is disabled should lose Bitrix24 access within one LDAP sync cycle (typically 15–60 minutes, configurable).

---

Email Integration: OAuth 2.0 Replaces Basic Auth

Because Microsoft has fully deprecated basic authentication for Exchange Online and Microsoft 365, any Bitrix24 deployment connecting to Microsoft 365 mailboxes must complete the OAuth 2.0 app registration first — only organizations on on-premise Exchange can still use standard IMAP credentials.

One often-overlooked consequence of connecting Bitrix24 to Microsoft 365 is the email authentication change. Microsoft has fully deprecated basic authentication (IMAP username + password) for Exchange Online and Microsoft 365.

What this means in practice: - If your team connects personal or shared mailboxes hosted on Microsoft 365 to Bitrix24, the OAuth 2.0 app registration described above must be completed first. - Once the Office 365 integration module is configured in Bitrix24, users select Office 365 as the email provider when adding a mailbox — authentication happens via OAuth token, not a stored password. - Organizations running their own on-premise Microsoft Exchange server (not Exchange Online) can continue using IMAP with standard credentials.

This is particularly relevant for enterprises migrating from legacy CRM systems — if you are moving from Salesforce or HubSpot, your email integration approach will likely need to change. See the Salesforce to Bitrix24 migration guide for a full transition checklist.

---

Planning Your Identity Integration: Key Questions

Before implementation, IT teams must answer scoping questions across four domains — directory structure, protocol choice, access control design, and timeline — with a well-structured AD/LDAP integration for 200–500 users typically requiring 2–5 business days, and complex SAML federations extending to 2–3 weeks.

Before starting implementation, your IT team should answer these questions. (They are a subset of the broader discovery process covered in the Bitrix24 onboarding questionnaire.)

Directory structure - Which OU or group should be the sync boundary? - Are there service accounts, shared accounts, or contractor accounts that should be excluded? - How are leavers currently handled in AD — immediate disable, or delayed?

Authentication protocol choice

Scenario	Recommended Protocol
On-premise AD, no cloud	LDAP / LDAPS
Microsoft 365 tenant	Azure AD OAuth 2.0
Mixed: on-prem AD + cloud IdP	ADFS as SAML IdP, or Azure AD Connect syncing to Azure AD
Third-party IdP (Okta, Keycloak)	SAML 2.0

Access control design - Will Bitrix24 roles map 1:1 to AD groups, or do you need a separate mapping layer? - Who has admin rights in Bitrix24 — should this require a separate privileged account?

Timeline and resources

A typical AD/LDAP integration for a 200–500 user deployment takes 2–5 business days of IT effort when the directory is well-structured. Complex SAML federations or multi-domain AD forests can extend this to 2–3 weeks. For full implementation cost context, see Bitrix24 implementation cost and timeline data.

---

Common Mistakes and How to Avoid Them

The six most damaging Bitrix24 identity integration mistakes — including using a privileged LDAP bind account, copying the Azure Client ID from the wrong tab, and ignoring client secret expiry — each cause silent or sudden authentication failures that are entirely preventable with correct first-time configuration.

1. Using a privileged bind account — A domain admin account as the LDAP service account is a security liability. Use a dedicated read-only account with access scoped to the relevant OUs only.

2. Copying the Client ID from the wrong Azure AD tab — The Client ID must be taken from the app's Overview tab. Copying from other locations in the Azure portal can cause silent authentication failures.

3. Not saving the client secret immediately — Azure only displays the secret value once. If you leave the page before copying it, you must delete the secret and create a new one.

4. Mismatched Redirect URIs — The URI registered in Azure AD must match exactly (including trailing slashes) what is shown in Bitrix24's Social Services settings. A single character mismatch breaks OAuth.

5. Ignoring certificate expiry — Client secrets in Azure AD have expiry dates. Set a calendar reminder to rotate the secret before it expires, or you will face a sudden authentication outage.

6. Skipping LDAPS in favour of plain LDAP — Unencrypted LDAP (port 389) transmits bind credentials in cleartext. Use LDAPS (port 636) or LDAP with STARTTLS, especially if the Bitrix24 server and the domain controller are on different network segments.

For IT teams deploying Bitrix24 alongside other business systems, the Bitrix24 for IT companies guide covers how to structure internal IT service workflows within the same platform.