Know the integration boundary 10 min read
Identity for AV: LDAP, AD, Entra, and Kerberos
Understand enough enterprise identity to specify and troubleshoot AV logins, group-based roles, and cloud access—without becoming the client's domain administrator.
- Distinguish a directory, LDAP, Active Directory Domain Services, and Microsoft Entra ID.
- Recognize where Kerberos, DNS, time, certificates, and group membership affect an AV integration.
- Translate directory groups into useful AV application roles.
- Define the information BMT needs while leaving directory administration with the client's IT owner.
The four names perform different jobs
A directory stores structured objects such as users, groups, computers, and service accounts. LDAP is a standard protocol applications can use to search and read a directory. Active Directory Domain Services—AD DS—is Microsoft's traditional on-premises directory and domain platform; LDAP is only one of the services it provides.
Microsoft Entra ID is a cloud identity provider used by Microsoft 365, Azure, and web applications. It commonly uses modern sign-in protocols such as OpenID Connect, OAuth 2.0, and SAML. Entra ID is not simply an AD domain controller hosted in the cloud, and it does not natively provide ordinary LDAP access.
What an AV platform usually needs
An on-premises AV management server offering LDAP integration may use a limited service account to find users and read group membership from AD DS. The application then maps approved directory groups to local roles such as administrator, support technician, or operator.
A cloud or browser application may instead redirect the user to Entra ID and receive a signed token after authentication. BMT Network Manager Web follows this modern model through Microsoft sign-in and Graph permissions; it is not an LDAP client.
Authentication proves identity. Authorization decides what that identity may do. If a user can sign in but receives access denied, the likely failure is group lookup, role mapping, consent, or application policy—not the user's password.
- Define the supported identity source and sign-in method.
- Map named client-owned groups to AV roles.
- Use least-privilege service accounts where required.
- Keep credentials out of drawings and closeout PDFs.
Kerberos matters mainly through its dependencies
Kerberos is the ticket-based authentication system widely used inside AD domains. A client first receives a ticket-granting ticket, then obtains service-specific tickets without sending its password to every server. An AV engineer rarely configures the Kerberos infrastructure, but should recognize its dependencies.
Kerberos depends heavily on correct DNS, service naming, and synchronized time. A domain-integrated AV server can therefore reject valid users when DNS points somewhere unhelpful, the clock is wrong, or a service name does not match. Capture the evidence and bring the client's identity administrator into the right part of the problem.
BMT's ownership line
BMT should define what the AV application requires, verify network reachability, configure supported integration fields, map approved groups to roles, and test acceptance and rejection. The client's IT team should own domain controllers, directory structure, identity lifecycle, certificate authorities, and organization-wide security policy unless those services are explicitly within BMT's scope.
Record server names, identity method, encrypted connection requirement, approved groups, role mappings, service-account owner, certificate owner, and renewal expectations. Do not record passwords. This is enough to engineer a dependable integration without adopting someone else's forest and all the squirrels living in it.
Put it in an AV system.
LDAP-backed AV monitoring
The platform finds the user but denies access. Network reachability, the bind account, and the directory search already worked; inspect group membership, nested-group support, and the group-to-role mapping next.
BMT Network Manager Web
Microsoft sign-in succeeds but project files remain unavailable. Investigate Entra application configuration, token scope, Graph permission, consent, and the user's file access—not LDAP settings or an on-premises domain controller.
- Directory
- Structured store of users, groups, devices, services, and related attributes.
- LDAP
- Protocol used by applications to access directory information.
- AD DS
- Microsoft's traditional domain and directory service.
- Entra ID
- Microsoft's cloud identity and access-management service.
- Kerberos
- Ticket-based authentication protocol used extensively in AD domains.
- IdP
- Identity provider that authenticates identities for applications.
Find the actual failed step
An AV server's LDAP connection test succeeds and it can find the user's name, but login returns not authorized. List what this proves, then inspect the expected group, membership lookup, nested-group behavior, and application role mapping before touching the user's password.
Three quick questions.
01Is LDAP the same thing as Active Directory?
No. LDAP is a protocol; AD DS is a directory and domain platform that supports LDAP among several other services.
02Is Entra ID simply an AD domain controller in Microsoft's cloud?
No. It is a cloud identity provider built around modern application authentication, not a native LDAP and traditional domain replacement.
03What identity information should BMT own in the AV documentation?
The required method, server or provider, encrypted connection, approved groups, role mappings, service-account owner, certificate owner, and renewal expectations—never the actual passwords.