Active Directory / LDAP
Many organisations still run their directory on-premise, and an assistant that cannot work with it cannot safely answer anything personal for their staff.
Many organisations still run their directory on-premise, and an assistant that cannot work with it cannot safely answer anything personal for their staff.
What Active Directory / LDAP holds, and why that matters here
Active Directory and LDAP directories remain the identity backbone for a large number of organisations, particularly in government, industry and any environment where cloud identity was not adopted or is only partly adopted.
For an assistant, the requirement is the same as with any directory: establish who is asking and what they are entitled to, using the organisation's existing authentication rather than inventing a parallel one.
- Users — accounts and their attributes.
- Groups — the membership that drives entitlement.
- Organisational units — structure that often maps to department.
- Authentication — the sign-in employees already use.
- Account state — enabled, disabled, expired.
Questions the directory lets Elbi answer
Who is asking?
Established from directory authentication rather than conversationally.
What are they entitled to?
Group membership determining what may be disclosed.
Who is in this department?
Directory structure questions asked routinely.
Who is my manager?
Reporting relationships from the directory.
Is this account active?
State, which prevents disclosure to departed staff.
Which team owns this?
Organisational attributes used for routing.
How Elbi works with an on-premise directory
- A dedicated bind account, not a person's loginYour directory team creates a service account for the connection and supplies its credentials. Every lookup runs as that one account, so its activity is attributable in your own logs, and disabling it stops the connection outright.
- A search base and an attribute listIn a default Active Directory an ordinary domain account can read much of the directory, so the bind account on its own is not the boundary. The boundary is what the connection is configured to query: the organisational units it searches under and the attributes it asks for — typically display name, department, title, manager, group membership and account state.
- The directory says who is askingStaff sign in with the account they already use on the network. Elbi resolves that account to its directory entry and reads its groups before answering anything personal, rather than taking the person's word for who they are.
- Groups decide what may be saidEach kind of answer is tied to directory groups your team names. Nested groups are resolved deliberately: the memberOf attribute lists only direct membership, so someone entitled through a parent group would otherwise be missed.
- Account state is read every timeA disabled or expired account is refused, whatever the conversation says. Because state is read at the moment of the question, a leaver disabled in the morning is refused in the afternoon without anyone touching the assistant.
- Account changes stay with ITPassword resets, unlocks and group changes are what people most often want from a directory, and they belong in your existing service desk process. Elbi explains that process and hands the request to a person; it does not write to the directory.
Scope and control on a directory connection
| Direction of access | Read-only. Elbi looks up who someone is, what they belong to and whether their account is active. Creating, editing and disabling accounts stays with the people and tools that do it today. |
|---|---|
| Who can see what | Personal answers are gated by the asker's own groups. Whether a colleague's department or manager is visible through Elbi follows your own policy — some organisations publish the org chart to everyone, others restrict it. |
| Credentials | The bind account is yours. Your team sets its password, rotates it on your own schedule and can disable it in Active Directory at any moment, which ends the connection immediately. |
| Transport | Directory traffic should be encrypted — LDAP over TLS, or StartTLS — because a plain LDAP simple bind sends the password readable on the wire. How the connection reaches a domain controller inside your network is agreed with your infrastructure team first. |
| Where data goes | Attributes read for a question serve that answer and nothing else. Message content is destroyed within 24 hours, usually as soon as the conversation ends, and no external AI service sees any of it. |
| Audit | Each lookup can be recorded — which account was looked up, when, and in which conversation — so "who has been asking about this person" has a checkable answer. |
| If a domain controller is unreachable | Elbi says it cannot confirm who the person is and limits itself to answers that need no identity. It does not fall back on an older copy of someone's groups. |
What this replaces
The on-premise case is common in exactly the organisations that care most about where data goes — government, defence-adjacent industry, utilities and large industrial groups. An assistant that requires cloud identity excludes them entirely.
The practical benefit is that entitlement continues to be managed where it always has been. Joiners, movers and leavers are handled by existing processes, and the assistant inherits the result rather than requiring a parallel process that would drift.
The security benefit is the same as with any directory connection: what the assistant may disclose is decided before the conversation starts, by systems that already exist, rather than by anything said during it.
Where on-premise directories matter most
Government
Where cloud identity is limited or absent.
Industrial and utilities
Long-standing on-premise directories.
Large enterprises
Hybrid environments where AD remains authoritative.
Any internal assistant
Entitlement that follows existing joiner-mover-leaver processes.
Where a directory connection earns its keep
The directory rarely answers the question people came with. It answers the question behind it: may this person be told. So the first thing worth connecting is usually not a directory lookup at all, but the personal question your staff ask most — leave balance, a payslip query, an access request — with the directory deciding who gets an answer.
The directory's own questions come second, and they are narrower than they look. "Who is my manager" and "who handles procurement in the Jeddah office" are answerable only if the manager, department and office attributes are actually maintained. In many directories they are filled in for some people and stale for others, and an assistant will repeat whatever it finds. A short check of those few attributes before launch is worth more than any configuration.
The third is group hygiene. Groups created for a file share years ago tend to outlive their purpose. If Elbi's entitlements hang on groups, those groups need an owner and a clear meaning, and a small set of purpose-named groups for the assistant is often simpler than reusing old ones.
What connecting Active Directory or LDAP involves
- Settle which directory is authoritativeIn a hybrid estate some people exist only on-premise, some only in the cloud, and most in both through Microsoft Entra Connect. Decide which source Elbi trusts for each population before anything is configured.
- Create the service accountA dedicated account with no administrative rights, denied interactive logon where your policy allows. Your team holds and rotates its password.
- Name the OUs, the filter and the attributesThe search base, a filter that leaves out service and shared mailbox accounts, and the attribute list. This short document is what your security team will actually review.
- Agree the network pathDomain controllers are normally unreachable from outside your network. Which one Elbi talks to, and by what route, is settled with your infrastructure team, with encrypted LDAP as a condition.
- Map groups to answersWhich groups may ask about which topics, and how nested membership is treated. Directories such as OpenLDAP often record membership on the group — member or memberUid — rather than on the user, so the mapping is written for your schema.
- Test with awkward accountsA disabled account, an expired contractor, someone entitled only through a nested group, someone with no manager recorded, someone who changed department recently. Each should get the answer your service desk would give.
Directory data and the PDPL
A directory is a register of employees, and nearly everything in it is personal data under the Saudi Personal Data Protection Law: names, job titles, phone numbers, reporting lines, office locations and, in many organisations, employee or national ID numbers kept in extension attributes. Staff photos are often stored there too.
The law's data-minimisation principle maps neatly onto the attribute list. Elbi needs enough to identify the asker and decide their entitlement; it does not need ID numbers, home details or photos, and they should not be on the list. Answers that disclose another employee's details, such as a colleague's mobile number, deserve the same thought: your address book may already publish them, but that is a decision to confirm rather than assume.
Staff should also be told plainly that the assistant reads their directory record to decide what it may tell them. It is one line in an internal notice, and far easier to include before launch than to explain afterwards.
What organisations typically see
How other assistants handle on-premise directories
Assistants that come bundled with a cloud productivity suite generally expect a cloud directory. An organisation whose identity lives only in on-premise Active Directory usually has to synchronise it to the cloud first — a reasonable project in its own right, but a large prerequisite for an assistant.
The usual workaround is a separate user list inside the chatbot, kept in step by hand or by a scheduled export. It is accurate on the day it is built and drifts afterwards, and the drift appears exactly where it matters: a leaver whose chatbot access outlived their directory account.
Then there is what staff already use — the Outlook address book, the intranet org chart, a call to the service desk. These remain perfectly good ways to look up a person. What they cannot do is let the directory decide what an assistant may disclose, which is the reason to connect it at all.
Common questions
Yes. On-premise directories are common in exactly the organisations most concerned about where data goes.
No. Entitlement stays in the directory and the assistant inherits it.
Common, and handled — which directory is authoritative for which population is settled during deployment.
No. The directory connection is read-only. Elbi can explain how resets work in your organisation and pass the request to your service desk, which keeps account changes inside the process your auditors already review.
A service account your team creates, with no administrative rights and a password you hold. Disable it and the connection stops; nothing on our side can re-enable it.
LDAP directories such as OpenLDAP follow the same pattern. Their schema differs, particularly for groups and account state, so the mapping is written for your directory rather than assumed from Active Directory.
Put your directory behind the answers
Elbi answering staff in Arabic and English, within the groups your directory already defines.