Because they operate at the layers where identity is actually enforced and consumed. These protocols expose authentication paths, directory relationships, and remote access behaviour. IAM teams need to understand them because weaknesses here often become the route to credential abuse, privilege expansion, or lateral movement.
Why SMB, LDAP, and Kerberos Still Matter to IAM Teams
These protocols sit at the enforcement layer, where identity claims become real access to file shares, directory objects, and authenticated sessions. IAM teams often focus on policy design and provisioning workflows, but SMB, LDAP, and Kerberos determine whether those decisions hold up under actual use. If they are misconfigured, over-permissioned, or poorly monitored, attackers can move from a valid account to broader privilege far faster than most identity programs expect.
The practical risk is not theoretical. Weak directory hygiene, stale service accounts, and exposed secrets often converge in the same environment, which is why NHI Management Group research on the 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM lags behind or only matches human IAM. That matters because SMB and LDAP are frequently consumed by service accounts, agents, and infrastructure workloads, not just human users. When identity controls fail here, credential abuse and lateral movement usually appear before a clean access review does. In practice, many security teams discover the problem only after a share, directory query, or Kerberos ticket has already been abused.
How SMB, LDAP, and Kerberos Shape Real Access Decisions
SMB, LDAP, and Kerberos are not just legacy protocols to inventory; they are part of the trust path. SMB controls how authenticated identities reach file and administrative resources. LDAP exposes directory structure, group membership, and attribute data that IAM systems depend on for authorization decisions. Kerberos issues time-bound tickets that can be reused within their validity window, which makes ticket handling, delegation, and service principal hygiene critical.
For IAM teams, the main operational task is to map identity policy to protocol behaviour. That means understanding where a user or service account can authenticate, what claims are returned, and which downstream systems trust those claims without additional checks. It also means monitoring for weak configurations such as unconstrained delegation, excessive directory read access, and service accounts that have broad rights across shares or domain services.
- Use LDAP to verify that group membership and attributes match intended access models, especially for privileged or inherited access.
- Treat Kerberos tickets as short-lived credentials that still need detection for unusual issuance, reuse, and delegation patterns.
- Review SMB access paths for administrative shares, old protocols, and service accounts with more reach than their workload requires.
- Align protocol-level controls with broader control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls so directory and session governance are not treated as separate problems.
Attackers frequently target these layers because compromise here can yield authentication material, directory context, and remote execution paths in one chain. NHIMG’s TruffleNet BEC Attack — Stolen AWS Credentials illustrates the broader pattern: once credentials are stolen, the real damage comes from how authentication paths and trust relationships let those credentials travel. These controls tend to break down in hybrid environments where legacy SMB shares, AD-integrated applications, and service accounts all share the same trust boundary because ownership and monitoring are split across teams.
Common Variations and Edge Cases IAM Teams Need to Watch
Tighter protocol control often increases operational overhead, requiring organisations to balance reduced lateral movement against compatibility, uptime, and admin effort. That tradeoff is especially visible in environments that still rely on legacy applications, domain-joined file services, or third-party tools that expect broad LDAP visibility.
Current guidance suggests treating these protocols differently by use case rather than applying one blanket rule. SMB access for a patching service, for example, should not resemble access for a human administrator. LDAP reads needed for directory lookup may be acceptable in one context but excessive in another if the account can enumerate sensitive attributes or nested groups. Kerberos delegation is another area where best practice is evolving: there is no universal standard for this yet, but least-privilege delegation and short-lived credentials are widely preferred over persistent trust.
Edge cases also matter. Cross-domain trusts, multi-forest directories, and appliance accounts can bypass the neat assumptions that IAM policy documents usually rely on. That is why identity teams need to trace actual protocol use, not just entitlement records, and why service account review should include ticket lifetimes, share mappings, and directory access paths. Without that visibility, a seemingly minor exception can become the easiest route into a broader environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | SMB, LDAP, and Kerberos enforce access decisions at the protocol layer. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Service accounts and protocol auth paths are core non-human identity exposure points. |
| CSA MAESTRO | MAESTRO addresses governance for identity-driven machine and agent access paths. | |
| NIST AI RMF | AI RMF is relevant when autonomous systems consume directory and auth protocols. |
Inventory protocol-using service identities and remove excess access from SMB, LDAP, and Kerberos paths.
