Active Directory / Basic / Lesson 5
LDAP, Kerberos, and sign-in flow
Distinguish directory access, ticket-based authentication, time and service-name dependencies, and the resource decision that follows sign-in.
On this page
Lesson goals
- Explain LDAP directory operations separately from Kerberos tickets.
- Identify discovery, clock, service identity, and permission stages.
- Reason about authentication evidence without handling credentials.
A directory query and a service ticket solve different problems
LDAP is a protocol for accessing directory information, including searches and authenticated operations under the applicable security policy. Kerberos provides ticket-based authentication involving a client, a Key Distribution Center on a domain controller, and a target service. It is not accurate to call every domain operation an LDAP login. A successful directory read also does not prove a later service ticket or file access succeeds. Keep the application’s actual protocol and bind/authentication method explicit. This lesson explains those roles and uses synthetic stage labels only; it sends no LDAP bind, ticket request, password, or network traffic.
A ticket refers to a particular service identity
A ticket-granting flow and a service-ticket flow are distinct stages. Service principal names help identify the account associated with a service, so a missing, duplicate, or mismatched service identity can cause failures that look unrelated to the user’s password. Aliases and load-balanced services need a documented identity design. Time consistency matters because authentication material has validity intervals and replay protections. Do not universalize one timeout or assume changing a clock is a harmless fix. Review the actual policy and evidence. Transport encryption, LDAP signing, and channel binding also have different roles explored in the hardening lesson.
Locate the first failed modeled stage
The complete Python fixture marks discovery, time, ticket issuance, and resource authorization as separate booleans. Its result identifies an authorization failure even though ticket issuance succeeded. It is not a Kerberos state machine and cannot interpret an actual Windows status code. The order is a teaching dependency model, not a complete protocol trace; real clients can use cached tickets and follow different supported paths. Use it to avoid a category mistake: fixing a directory password does not logically repair every downstream access decision. Real evidence should identify the actor, target service, time, and failure category.
stages = [
("discovery", True),
("time_policy", True),
("ticket_issued", True),
("resource_authorization", False),
]
failed = next((name for name, passed in stages if not passed), "none")
print(failed)
resource_authorization
The model prints resource_authorization. It contains no credential, ticket, directory connection, or live event lookup.
Protect the access method as well as the account
An application should use an approved authenticated and protected directory-access method. LDAP signing provides integrity in its applicable SASL context, not general confidentiality; TLS and sealing address other protections, and simple binds require appropriate transport protection. Current defaults and enforcement differ by server/client version and deployment history, so inspect Microsoft guidance for the actual environment. The planning record below names evidence categories without specifying credentials or running a client. Never disable a security control just because an old application fails after a change; identify its protocol capabilities and migration contract first.
{"client":"workstation-17","domain":"ad.example.test","target_service":"course-files","evidence":["controller_selected","time_context","authentication_stage","resource_decision"],"credentials":"not_collected"}
The record separates observations needed for diagnosis and explicitly excludes credential collection. It does not request tickets or authenticate.
LDAP search contracts
An LDAP search names a base DN, scope, filter, and requested attributes. Base, one-level, and subtree scopes cover different regions. The planning example selects a person/user by account name and requests only displayName. Escape external filter values with documented library rules; filter escaping differs from DN escaping. Bound results and handle paging/referrals deliberately. Neither a valid filter nor a readable attribute proves authorization to modify the object.
{"base_dn":"OU=Learners,DC=ad,DC=example,DC=test","scope":"subtree","filter":"(&(objectCategory=person)(objectClass=user)(sAMAccountName=learner17))","attributes":["displayName"],"mode":"documentation_only"}
The record states selection intent only. It opens no connection, performs no search, and fabricates no returned objects.
Preserve the distinction between authentication and access
A failed sign-in, a failed service-ticket request, and access denied by an application can require different owners and evidence. Use approved sanitized event records and application context rather than collecting secrets. Account lockout, disabled state, expired access, name resolution, time, and service identity are hypotheses to distinguish, not a checklist of changes to perform. NTLM fallback is not proof that a Kerberos design is correct, and a successful retry on another controller can point to consistency or locality issues. State what remains uncertain. This course never generates authentication traffic or changes passwords to validate a lesson.
Common errors and fixes
Every access failure is labeled a bad password.
- Why it happens
- Protocol stages and resource authorization were collapsed.
- How to fix it
- Identify the failing stage before an account change.
- Prevent it next time
- Record ticket and resource outcomes separately.
LDAP signing is described as encryption.
- Why it happens
- Integrity and confidentiality were conflated.
- How to fix it
- Review signing, TLS, sealing, and channel binding distinctly.
- Prevent it next time
- Match the control to the actual bind method.
A service alias breaks Kerberos while ordinary DNS works.
- Why it happens
- Host resolution was mistaken for correct service identity.
- How to fix it
- Review the approved service-principal mapping and evidence.
- Prevent it next time
- Include aliases in service identity design tests.
Check your understanding
1. Change ticket_issued to False in the model. What is now the first failed stage, and why does the model not prove the cause of that failure?
Show worked solution
The model prints ticket_issued because earlier declared stages still pass. It cannot distinguish an actual account condition, service-name issue, policy mismatch, or another protocol error; it contains only booleans. Use authorized stage-specific evidence to narrow that cause. The output is a classification aid, not permission to reset an account or alter authentication policy.
2. A signed LDAP connection is readable in transit under the declared non-TLS model. Is signing necessarily broken? Explain the missing property.
Show worked solution
Not necessarily. Signing addresses integrity/authenticity in its applicable context, while confidentiality requires an appropriate encrypted transport or sealing arrangement. Verify the exact method and policy rather than assuming all protections are identical. The review must consider client/server support and migration impact; the lesson does not authorize weakening or changing a real connection.
Key takeaways
- LDAP access and Kerberos tickets serve different roles.
- Discovery, time, service identity, and permission each need evidence.
- Never substitute credential collection for diagnosis.