YanoSecActive Directory stores centralized identities and policy. A domain controller holds directory services; it is a role in an administrative domain, different from a website’s DNS name. Before interpreting a sign-in record, identify which authentication protocol its messages describe.
Kerberos uses a trusted Key Distribution Center, KDC. A client obtains a ticket-granting ticket, TGT, and uses it to request a service ticket; a service ticket is then presented to a particular service. NTLM instead uses a challenge, a fresh value sent by the server, and a response computed using the client’s secret. Both flows carry sensitive authentication material.
Before you begin
- Recommended first
- The rule for every tool from here on, Notes: scope, command, result, time, Passwords, hashes, and dumps, Access control and IDOR
- Estimated time
- 14 min reading, 14 min activity. Setup and optional practice may take longer.
- Where you work
- Use only the supplied North Desk fictional cards and source in a desktop or mobile browser. Keep predictions in private notes. No login attempt, recovery tool, framework module, permission change, domain setup or target connection is required. Optional later lab setup has a separate budget.
- Without a lab
- All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.
After this lesson you can:
- Name the client, the KDC, and the service in the ticket flow.
- Name the challenge and the response in the other flow.
- Refuse to call the two flows the same protocol.
01Example
Fresh authored service-ticket model. This is a role diagram, not a full protocol exchange or captured ticket.
Client Noor → trusted KDC: request a ticket for the print service
KDC → client: service ticket
Client → print service: present ticket
Interpretation: the named trusted ticket issuer distinguishes this model.
A prior identity/TGT exchange is omitted from this small view.02Two flows, not one
A principal is an identity participating in authentication, such as a user or service. In a Windows AD domain the KDC runs on a domain controller and uses the directory’s account data. Authentication establishes an identity; authorization still decides which resource that identity may use.
In the simplified NTLM flow the client identifies its account, the server sends a challenge and the client returns a computed response. The server or trusted checking party validates it. The response is not the plaintext password, but remains sensitive; do not paste it into a report. This model does not teach response algorithms or make a modern protocol-selection recommendation.
Delegation means a service may act on a client’s behalf toward another service under specified conditions. The later graph names this relationship. A service ticket and a delegation grant are concepts to read here, not operations to perform.
Distinguish a ticket-based identity flow from a challenge-response flow using its actors and messages.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Playback is optional. Step through at your own pace.
- Client Noor → Trusted KDCRequest service ticketFor the print service; prior identity/TGT exchange omitted.
- Trusted KDC → Client NoorService ticketAuthored simplified ticket role; no captured ticket.
- Client Noor → Print servicePresent service ticketService authorization is still a separate gate.
Noor requests a print-service ticket from the trusted KDC.
Follow the explanation
- Noor requests a print-service ticket from the trusted KDC.
- The ticket returns to Noor and is presented to the print service.
Read every state and value
1. Noor requests a print-service ticket from the trusted KDC.
- Messages shown
- request
- Current message
- request
- Policy decisions
- Status: pending
- Participant roles
- Actor: Client Noor; Text: Client Noor requests and presents the service ticket in this model. · Actor: Trusted KDC; Text: The earlier identity/TGT exchange is omitted. · Actor: Print service; Text: Print service receives the modeled ticket; separate authorization is not established.
2. The ticket returns to Noor and is presented to the print service.
- Messages shown
- request · Service ticket · present
- Current message
- present
- Policy decisions
- Status: not-established
- Participant roles
- Actor: Client Noor; Text: Client Noor requests and presents the service ticket in this model. · Actor: Trusted KDC; Text: No captured ticket or full protocol exchange exists. · Actor: Print service; Text: Authorization remains separate and is not supplied.
03Label the flow that has a KDC
Use the full fictional K and N cards. No domain, ticket bytes or connection is required.
Two authentication flows
Label: original fictional cards. No ticket was requested and no challenge was sent.
Flow K, three parties from the Windows Kerberos overview.
Client: a security principal, such as user lea.
KDC: Key Distribution Center. On a Windows domain the overview says it runs on a domain controller and uses the Active Directory database.
Service: files-3, the service lea wants.
K1. The client contacts the KDC and receives a ticket-granting ticket, a TGT.
K2. The client presents the TGT to the KDC and asks for a service ticket for files-3.
K3. The client presents that service ticket to files-3.
The overview says the service can then check the ticket without asking a domain controller on every connection.
No ticket bytes are printed. A ticket is still a secret on a real network.
Flow N, challenge-response, from Microsoft's NTLM descriptions.
N1. The client sends a user name.
N2. The server sends a challenge, a random value.
N3. The client returns a response computed from the challenge and the password secret.
N4. The server, or a domain controller that holds the account secret, checks the response.
The password itself is not the response. The response is still authentication material. Keep it private.
Flow N has no KDC and no ticket.
These cards do not say which protocol a real Windows sign-in used. A sign-in has to name its flow.
- Mark client, KDC and service on Flow K. Follow TGT, request for a service ticket and presentation of that ticket.
- Mark username, challenge, computed response and validation on Flow N. Its depicted exchange has no KDC ticket issuance.
- Explain the differing mechanisms using actors/messages rather than assuming every Windows sign-in uses the same flow.
- Stop with the annotated cards. Do not request a ticket or capture an authentication exchange.
04Optional challenge
For about ten optional minutes, write why both a ticket and a challenge response stay out of shared notes even though neither is the user’s plaintext password. Your rubric is that authentication material can remain sensitive and reports should use safe descriptions rather than secret bytes.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Ticket card A: fictional party namesOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Client: user Emi. Trusted KDC: dc-paper. Requested service: Archive.
T1: Emi receives a TGT from dc-paper.
T2: Emi presents the TGT to dc-paper to request an Archive service ticket.
T3: Emi presents that service ticket to Archive.
No ticket bytes or real exchange are supplied.
Response card B: independent flowOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
R1 client sends an account name.
R2 server sends a fresh challenge.
R3 client returns a response computed using the challenge and a password secret.
R4 server or trusted checking party checks the response.
No KDC or ticket occurs in this model.
06Explain the evidence and its limit
Optional self-check: describe TGT versus service ticket, then contrast that flow with a server challenge and response.
Review it: include the KDC’s role, keep authentication separate from authorization, and omit all real ticket or response bytes.
07Common mistakes
If a TGT is added to the NTLM card, return to the supplied message sequence rather than blending the two models.
If authentication implies access to every share, separate identity checking from authorization.
If a response seems safe to publish because it is not a password, identify its authentication role and redact it.
References
- Kerberos authentication overview in Windows Server
Official background on the authentication, permission or directory concept used in the supplied reading model.
- Windows: Key Distribution Center
Official background on the authentication, permission or directory concept used in the supplied reading model.
- MS-NLMP: 1.3 Overview
Official background on the authentication, permission or directory concept used in the supplied reading model.
- Microsoft NTLM
Official background on the authentication, permission or directory concept used in the supplied reading model.