Domain Controller, client, and member server: Who does what in the system?

1. Core mechanism

Requesting, processing, and using an identity

The WS01 client requests a service context for tunahan. The KDC on DC01 processes a ticket request for cifs/FS01.iyelabs.example, and the client then presents the ticket directly to the service on FS01.

The DC does not decide the file DACL on FS01. After the service accepts the ticket, a local logon creates a session or token context, and FS01 evaluates authorization for the requested resource.

The DC is not on every service-connection path

A Kerberos service ticket is presented directly to the target service. The service does not contact the DC for a new ticket on every connection; ticket caching and protocol details prevent a simple one-ticket-to-one-4769 assumption.

This distinction separates architecture from failure analysis: ticket generation by the KDC does not mean that the target service accepts the connection or permits access to the resource.

Two hosts, two records, two questions

Event 4769 on DC01 shows service-ticket processing. Event 4624 on FS01 shows that a logon session was created on the target. File access requires separate object-access evidence.

LogonGuid can assist correlation, but a zero GUID, ticket reuse, time and collection delays, and separate data paths defeat a universal one-to-one join.

Evidence boundary

The artifact pair is a synthetic subset of fields from the referenced documents; it was not taken from a real AS/TGS/AP flow. The matching GUID exists only to demonstrate the application’s comparison behavior.

Exceptions in service/DC interaction, including PAC processing and NTLM paths, are not generalized in this introductory lesson; corresponding claims are left to later courses.

State and data flow

1. WS01 acquires a Kerberos context for its domain principal.
2. When accessing a service, it requests a service ticket from DC01/KDC.
3. DC01 processes the request. With the relevant Kerberos Service Ticket Operations auditing enabled, it records Event 4769 in its own Security log.
4. WS01 presents the ticket directly to the target service on FS01.
5. If FS01 accepts the ticket and creates a network logon session, the relevant Logon auditing records Event 4624 in FS01’s Security log.
6. FS01 evaluates its own resource security descriptor using the token.
7. The DC record, target session, and object access are interpreted as separate evidence.

2. Exploitation

Broken trust assumption

Broken assumption: “The server only carries data; local administrator or SYSTEM access cannot affect the domain, and it does not lead directly to Domain Admin.” The immediate effect is limited to the host. Expansion to the domain depends on stronger identities and rights available on, or trusted by, that host.

Technical prerequisites

• Local manager, SYSTEM or equivalent service control on member server.
• Dedicated domain account session on the server for wider domains, strong service account, reused local credentials or private domain right given to the machine account.
• Using the obtained ID in other systems or having truly effective right on AD objects.

Exploitation mechanism

Member server control primarily affects the service, processes, local SAM, logon session and data. The bounce to the domain is not automated: the attacker must access a stronger credential, use the right to the service/machine account or find a reused secret that is accepted in another target. The privileged control in DC threatens a different and wider trust limit for systems managed by AD DS data and domain.

Do not equate host control with domain control

The local Administrators membership in FS01 is not a IYELABS\Domain Admins membership. Start effect is the local security area of FS01.

If you have wider ways, it explains the concrete dependency: privileged session, service account, machine account right or reused credential.

Role separation also separates the attack surface

Client credential usage point, DC central authentication/ticket point, member server is credential acceptance and resource decision point. The effect of each one is not the same.

The conclusion “the server is addressed, so the domain is owned” but it can be installed when the indirect authentication and right chain is proved.

3. Defense & Detection

Telemetry scope

• DC evidence: Security/4769, produced by Audit Kerberos Service Ticket Operations on domain controllers.
• Correlation evidence: Security/4624 on FS01, produced by Audit Logon when the target session is created.
• These events do not require an object SACL. Object Access auditing and an appropriate SACL are separate requirements when proving file or object access.

Events and relevant fields

• 4769 / TargetUserName, ServiceName, ServiceSid, TicketEncryptionType, IpAddress, Status and LogonGuid: KDC’s ticket processing context.
• 4624 / TargetUserSid, TargetUserName, TargetDomainName, TargetLogonId, LogonType, AuthenticationPackageName, IpAddress and LogonGuid: session context created in target.
• 4769 Version 0 uses the classic documented field set; Version 2 does not add the fields used by this artifact.
• 4624 LogonType 3 means Network; the synthetic value selects Kerberos as AuthenticationPackageName. These values are not lab results.

Start with the observation point

The originating host matters as much as the event ID. Event 4769 answers the KDC question; Event 4624 answers the target-logon question.

Combining two records into a single “successful access” event hides the distinction between correlation and authorization.

Treat correlation as evidence, not as proof

A matching LogonGuid helps connect records, but it cannot prove more than the events establish individually. Object access requires additional evidence.

If the GUID is zero, correlation is less precise. Evaluate host, account, address, and time together against the environmental baseline.

Detection logic · XPath

DC akışı: *[System[(EventID=4769)]]
Kaynak akışı: *[System[(EventID=4624)]]

Query assumptions

• These are two separate Windows Event Log XPath candidate filters; XPath does not join events across hosts.
• Perform correlation in the SIEM or application layer; a matching, non-zero LogonGuid is only candidate evidence.
• With a zero GUID, the account provides weaker evidence for correlating client address, target, and a narrow time range; no universal correlation window is established.
• The queries and synthetic pair were not run against an actual Windows or SIEM dataset.

False positives

• Busy application servers and service accounts can produce many normal 4769 and 4624 records.
• A cached ticket may not be accompanied by a new 4769 for every target connection.
• NAT, clock differences, and collection delay can mislead address and time correlation.
• Negative example: these records do not prove that FS01 generated 4624 or that a file was accessed.

Hardening

• Restrict logon of dedicated domain accounts to the member servers that require them.
• Keep local Administrators membership and service-control rights to the minimum necessary scope.
• Grant service and machine accounts only the domain rights they require; review those right chains regularly.
• Perform management operations from trusted, separate management hosts; protect DCs as a distinct critical layer.
• Verify separate collection of DC 4769 and member-server 4624 streams, then measure GUID completeness and correlation behavior with a controlled lab flow; this validation has not yet been performed.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4769</EventID><Version>0</Version><Channel>Security</Channel><Computer>DC01.iyelabs.example</Computer></System>
  <EventData><Data Name="TargetUserName">tunahan@IYELABS.EXAMPLE</Data><Data Name="TargetDomainName">IYELABS.EXAMPLE</Data><Data Name="ServiceName">FS01$</Data><Data Name="ServiceSid">S-1-5-21-111111111-222222222-333333333-1108</Data><Data Name="TicketOptions">0x40810000</Data><Data Name="TicketEncryptionType">0x12</Data><Data Name="IpAddress">::ffff:192.0.2.21</Data><Data Name="IpPort">51477</Data><Data Name="Status">0x0</Data><Data Name="LogonGuid">{8f2a4c11-5d90-4a37-9be2-71c4ad0f3e55}</Data><Data Name="TransmittedServices">-</Data></EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4624</EventID><Version>2</Version><Channel>Security</Channel><Computer>FS01.iyelabs.example</Computer></System>
  <EventData><Data Name="TargetUserSid">S-1-5-21-111111111-222222222-333333333-1105</Data><Data Name="TargetUserName">tunahan</Data><Data Name="TargetDomainName">IYELABS</Data><Data Name="TargetLogonId">0x9c53</Data><Data Name="LogonType">3</Data><Data Name="AuthenticationPackageName">Kerberos</Data><Data Name="WorkstationName">WS01</Data><Data Name="IpAddress">192.0.2.21</Data><Data Name="LogonGuid">{8f2a4c11-5d90-4a37-9be2-71c4ad0f3e55}</Data></EventData>
</Event>

Two reality checks

Assumption: When the member server authenticates the domain user, the DC also decides all resource permissions.

In fact: The DC handles identity and ticket processing, and the client presents the ticket to the target service. The member server creates the session and makes a separate authorization decision for its own resource using its security descriptor.

Assumption: Being a local administrator on a member server directly makes the account a Domain Admin.

In fact: The immediate effect is limited to the host’s local security boundary. Domain impact occurs only through actual domain rights held by a stronger identity on the host, a reused credential, or a service or machine account.

Sources

• Microsoft · Kerberos authentication overview
  Introduction, “How Kerberos authentication works”, and “More efficient authentication to servers”: the KDC’s role on the DC and presentation of a ticket to the service.
• Microsoft · MS-GPOD glossary
  “domain controller (DC)”: the AD DS data-store and replication role.
• Microsoft · 4769(S, F): A Kerberos service ticket was requested
  Event Description, Version 0 XML, and field descriptions including Logon GUID; the event’s observation point on the DC.
• Microsoft · 4624(S): An account was successfully logged on
  Event Description, Version 2 XML, and descriptions of Logon Type, Authentication Package, and Logon GUID.
• Microsoft · Best practices for securing Active Directory
  “Credential theft” and “Use secure administrative hosts”.