Integrating Bitrix24 with Active Directory: where login breaks down
While there are only dozens of employees, the discrepancy between the directory and the portal is almost invisible.
A new person is onboarded manually: first an account in Active Directory, then a separate one in Bitrix24 — with the department, group and permissions selected by hand. The two databases live in parallel, and any change has to be entered twice.
This breaks down predictably. On termination, the domain account is blocked the same day, but the portal account is forgotten — and the former employee keeps seeing tasks, files on the disk and message history, signing in with a saved session or from the mobile app.
The reverse situation is no less costly: the domain password changes under policy, the portal keeps the old one, portal login with the domain account fails, and the person goes to support.
A separate headache is mismatched accounts. An employee moves to another department or changes their last name: the directory already reflects it, while on the portal they remain listed in the old place for months and get access to other people's projects.
Duplicates for a single person — domain, portal, account in 1C — break both reporting and access rights: it is unclear who exactly opened a document.
Integrating Bitrix24 with Active Directory removes manual employee creation: the portal reads the directory tree, pulls in full name, position, department and manager, and blocking a record in the domain automatically closes access to the portal.
But it is not a single checkbox in the settings: you need to choose which attribute serves as the login, how to map departments, what to do with records already created manually, and who remains the portal administrator if the directory becomes unavailable. Let's break down how this is handled and what to consider before enabling synchronization.
What single sign-on through the corporate directory delivers
Single sign-on is built on linking the portal to the corporate directory over LDAP: we define the rules for mapping account attributes — login, email, department, group membership — and turn directory groups into portal departments and roles.
The password is not stored in Bitrix24: login happens under the domain account, and rights are inherited from Active Directory rather than assigned manually to every newcomer.
The time to onboard a new employee drops from hours of manual work to minutes. The account is created in the directory, and on first login the portal pulls in the department, manager and the required set of permissions on its own.
Requests to create a profile and grant access leave support as a category — one process remains, run by HR.
Closing access on termination stops depending on the human factor. Blocking the account in the directory revokes access to all connected services — portal, mobile app, external segments — and active sessions are reset at the next synchronization.
The window in which a departed employee still sees messages, tasks and files shrinks from days to minutes.
The password load on support drops predictably: resets and recovery move to the directory, where they are managed by the directory service rather than a separate portal service.
Tickets caused by forgotten and expired passwords are usually the largest category of requests; after switching to single sign-on their share falls severalfold. At the same time, the account with a local password that gets forgotten on termination disappears.
Account synchronization options: a comparison
The directory remains the source of truth: accounts, departments, positions and managers live in Active Directory, while Bitrix24 receives their reflection for the portal, chats and internal processes.
There are three migration scenarios, and they differ not in the tool but in the exchange frequency and the way changes are transmitted — from a one-time load to reacting to directory events.
| Option | When it fits | Limitations |
|---|---|---|
| One-time employee export | Portal launch, migration from another system, headcount changes rarely | Diverges from the directory at the first change, must be repeated manually, terminations are not tracked |
| Regular scheduled synchronization | Moderate turnover, predictable headcount reconciliation needed | Delay until the next run, a full traversal loads the controllers, delta calculation required |
| Event-driven change delivery | Hires, transfers and terminations must be reflected immediately | Requires rights to read directory events and a reliable queue; on failure, catch-up by reconciliation is mandatory |
Some limitations are shared by all options.
Passwords are not transferred to Bitrix24 — how an employee signs in is decided separately; nested groups and non-standard fields only come through explicit attribute mapping; a conflict on login or email blocks the record until it is resolved manually.
A policy for terminated employees is also needed separately: delete the record or deactivate it while preserving the history of messages and tasks.
In practice, a schedule is taken as the baseline, event-driven delivery as an accelerator on top of it, and a one-time export is kept for the initial population.
Stages of Bitrix24 and Active Directory integration: audit and handover
Preparation takes more time than the configuration itself: until departments and groups are sorted out, exchange with the directory produces unpredictable results. We work in stages — from the directory audit to handing the system over to administrators.
-
Audit of the corporate directory. We capture the structure of departments, the composition of groups and the number of accounts the portal actually needs; we check disabled and service accounts separately — they most often break the selection rules.
-
Group-to-role mapping scheme. We agree on a table of "directory group → role in Bitrix24", including nested groups, and fix what rights each link grants and what happens when an employee is transferred to another department.
-
Access and a secure channel. We create a dedicated account with read-only rights, restrict the set of exported attributes and enable encryption of the connection to the domain controller.
-
Test environment. We deploy a copy of the portal and connect it to a separate department: we run through login, automatic account creation, password change, termination and rehire.
-
Debugging edge cases. Duplicates, matching logins, an employee in several groups at once, long absence — each case gets a documented rule rather than a manual edit.
-
Acceptance and handover to administrators. We run the agreed checklist on the production environment, enable scheduled exchange and hand over to your specialists the mapping scheme, the connection regulations and the rollback procedure.
After that, changes in the directory — hires, transfers, terminations — are reflected on the portal without manual actions by an administrator.
Access policies, diagrams and documentation delivered
Integration is considered complete not when domain-account login works, but when its maintenance no longer depends on the person who configured it.
That is why, along with a working exchange, the client receives a set of artifacts that let any administrator reproduce the logic of the connections and change it without the risk of breaking access.
- Group mapping table — a table showing, for each directory group, which rights and roles it grants on the portal, including nested and service groups that usually remain in the shadows and grant extra access.
- Access policies — rules on who gets into which sections, with an explicit precedence of deny over allow and a separate description of exceptions for external contractors.
- Connection diagram — a diagram of the flow from the directory controller to the portal, with failure points and the procedure to follow if the exchange stops.
- Employee onboarding regulations — the sequence from request to access appearing: account creation, adding to a group, expected time until synchronization.
- Administrator guide — typical operations: transfers between departments, blocking on termination, manual exchange run, reading the log during desynchronization.
- Maintenance documentation — the schedule of checks, integrity control of mappings, the procedure for editing rules when the directory structure changes.
- Rollback procedure — how to restore the previous set of rules and what to check after the rollback so that access is fully restored.
We hand over the artifacts in editable form and verify them in the test environment: the client's administrator walks through the regulations independently, and we go over the places where the wording allows a double reading.
Case study: how manual employee creation was eliminated
The client is a distributed team: several offices, remote employees, a constant stream of hires and terminations.
The directory was the source of truth about people, while profiles in Bitrix24 were created by hand: a ticket to the support service, manager approval, department, groups, disk access.
Before implementation, onboarding a single employee took from several hours to two days, and closing access on termination depended on whether someone sent the request in time.
What was changed
We set up one-way synchronization: departments, positions and attributes are pulled from Active Directory, and Bitrix24 remains a consumer and does not write to the directory.
Rights are inserted based on group membership rather than assigned manually — a new employee gets the required set at the moment of first login.
Results before and after
Employee onboarding time dropped from hours to minutes and stopped depending on the administrator's workload. Disabling an account in the domain automatically closes access to the portal, so no "forgotten" active profiles remain.
Routine requests like "create, add, remove" have left the support queue, and the distributed team no longer waits for an administrator in another time zone.
How does directory synchronization differ from single sign-on?
Synchronization and single sign-on solve two different problems, and an attempt to cover both with a single "configure LDAP" item usually surfaces already at the launch stage.
The first is responsible for the roster of employees: which accounts exist on the portal, which departments they belong to, who reports to whom.
The second is responsible only for password verification — whether the corporate directory confirms that the person signing in is who they claim to be.
| What we compare | Directory synchronization | Single sign-on |
|---|---|---|
| Purpose | roster of accounts, departments, groups | password verification at login |
| Where the password is stored | on the portal or in the directory as the source of attributes | only in Active Directory |
| What is transmitted | full name, email, manager, department | the verification result, without the data itself |
| Direction | directory → portal, less often back | portal → directory, an inbound request |
| Directory failure | the portal stays up, but the roster goes stale | new login is impossible without a fallback |
In practice, the two modes are almost always enabled together: the roster is pulled on a schedule, and login goes through the directory. The key fork is the record matching rule: by login or by email.
It cannot be changed on the fly, otherwise duplicate accounts appear and some employees lose access to their tasks and messages.
We design the behavior for directory unavailability separately. The connection is kept over a secure channel through a backup domain controller, the service account is granted read-only access, and administrators retain a local emergency login.
Without this, the failure of a single directory server halts the work of the entire office — and that is no longer a configuration matter but a managed risk.
Common technical doubts before connecting the directory
Before connecting the directory, technical leads raise the same questions: what will happen to accounts that already exist, can we synchronize only part of the structure, how will the integration behave if the domain controller is unavailable, and what to do about external contractors. Below are substantive answers, without generic wording.
We already have employees in Bitrix24 — do we create them again?
No. Matching is done by a stable identifier — email address or the record's ID in the directory — so existing users are linked to Active Directory accounts rather than duplicated. Those who are not in the directory remain local and are not affected.
Before the first run we take a snapshot of the current state and run the matching rules in report mode — without writing changes.
We need to synchronize only part of the departments — is that possible?
Yes, the filter is set by directory branches: we include the required departments and individual employees and ignore the rest. The rules differ for different branches — for example, the sales department transfers one set of attributes and the warehouse another. When an employee moves to another department, the set of transferred data updates automatically.
What happens if the directory becomes unavailable?
Login to the system is not blocked: verification runs against cached data, and changes accumulated during the outage are applied after connectivity is restored. The queue is processed without manual intervention, and conflicting records go into a separate report.
We separately agree on the maximum period of operation without the directory and the behavior during a prolonged outage.
What about external contractors?
We keep them outside the directory: local accounts with a limited set of rights and an expiry date. This way external specialists do not enter the common structure, do not inherit department rights and do not interfere with synchronization. Access is closed automatically when the term expires — no manual tracking needed.
Let's discuss the task and come back with an estimate and a plan
To discuss the task substantively and come back with an estimate and a work plan rather than clarifying questions, we need the input data for the estimate.
Integrating Bitrix24 with Active Directory almost always hinges not on the exchange itself but on discrepancies in the data model: the directory has one department hierarchy, the portal another; some employees were created manually, some came from external systems.
The more precisely you describe these details, the fewer iterations it will take to reach agreement.
- Directory composition: domains and trusts between them, controllers, available connection points and the secure protocol, whether there is a separate environment for contractors.
- Structure of departments and groups: the department tree, security groups, branches — these are the basis for the matching rule with portal departments.
- Roles and rights: which groups grant which permissions — administrator, manager, employee; whether a mapping matrix is needed.
- Synchronization scenarios: login with a domain account, automatic creation on hire, blocking on termination, updating position and manager on transfer.
- Environments: portal in the cloud or on your own server, whether there is a test environment and how settings are transferred to production.
- Access requirements: a read-only service account, network permissions, who on the client side provisions and maintains them.
- Constraints and history: the number of users and groups, the required synchronization frequency, previous configuration attempts and errors from the logs.
Describe this in an email or let's discuss it on a call — we will come back with an estimate, a work plan and areas of responsibility.