The difference between authentication and authorization: Why proving your identity is not permission to access

1. Core mechanism

This lesson establishes the boundary between authentication and authorization: authentication proves identity and generates an access token; authorization compares that token with the DACL of a specific object for a specific requested right. How the groups are collected for the token is at 05.01; reading of security descriptor/DACL/ACE at 05.03; Sequential evaluation of allow/deny/inheritance is covered in 05.04. The focus here is why the difference between 'I have proven my identity' and 'I am authorized to perform this action' is separate at the mechanism level.

Interfaces and specifications

• Authentication: a principal proving its claimed identity (interactive logon, Kerberos ticket, credential verification); The result is a logon session and access token.
• Access token: output of authentication and input of authorization; It carries the user SID and group SIDs.
• Authorization / access check: the system's decision to grant/deny access by comparing the SIDs in the token with the ACEs in the DACL of the target object for the desired access mask.
• Requested access mask: set of bits that indicate what rights (e.g. FILE_READ_DATA, FILE_WRITE_DATA) the access request requests; access check is executed according to this mask.
• Per-resource decision: each object has its own security descriptor; The same token may be authorized in one object but unauthorized in another.
• Kerberos ticket: carries proof of identity; Having a ticket does not include resource authorization, it only covers the authentication side.

Two separate questions: who are you and what can you do?

Authentication answers one question: 'is the identity you claim really you?' An interactive logon, a Kerberos ticket, or a credential verification provides this. When you are successful, the system gives you a logon session and an access token tied to this session. At this point no resources have been accessed yet; Only your identity has been proven.

Authorization answers a completely different question: 'do you have permission to perform this particular operation on this particular object?' This decision is the job of that object's security descriptor, not the ID. So authentication answers the 'who' question once; authorization answers the question 'what can it do' separately for each object and each requested right.

Bridge: access token

The structure that connects the two questions is the access token. When authentication is completed successfully, the system puts the user's SID and all group SIDs into the token; This token is a portable digest of identity. Authorization reads this token: During access check, the SIDs in the token are compared with the trustees in the ACEs of the object.

The critical point is this: the token is not a 'key', but a 'set of assertions'. It doesn't say 'I can access this resource'; It just says 'I am these SIDs'. Each resource decides whether it can access or not by looking at how it meets those SIDs in its own ACEs. Therefore, having a valid token does not guarantee access to any resources.

Access check works according to the requested right

When a thread accesses an object, the system either grants or denies access. If the object does not have a DACL (NULL DACL), the system grants access; If DACL exists, it sequentially examines the ACEs that match the SIDs in the token for the desired access mask. If a matching access-denied ACE denies one of the requested rights, access is denied; Access is granted if one or more access-allowed ACEs grant all requested rights; If, when all ACEs are examined, there is still a requested right that has not been granted, access is implicitly denied.

The result of this is that authorization is rights-based, not 'all or nothing'. On the same object, the same user can be authorized to Read and unauthorized to Write; Because access check evaluates each requested right separately. 'Being authenticated' adds no rights to this assessment; It only determines which SIDs the token carries.

This lesson’s Read/Write example uses an ordinary token without an enabled applicable bypass privilege and an ordinary file access path. A token carries privileges as well as SIDs. Enabled SeBackupPrivilege or SeRestorePrivilege can affect normal ACL checks for their defined file operations. A DACL result therefore does not describe every Windows access path.

Ticket covers authentication, not authorization

When a user authenticates in Kerberos, he receives tickets containing proof of identity. These tickets answer the question 'who are you' and determine which group SIDs go into the token. But owning a ticket does not include any specific right to any file, share, or directory object; that right is granted only by the target resource's DACL.

This distinction is also decisive from a security perspective: even if the authentication side is compromised (e.g. a credential/ticket is misused), the access obtained is still limited to how much the token's SIDs correspond in each resource's DACL. So authentication opens the door, but authorization keeps each room unlocked separately.

State and data flow

1. u.arin validly authenticates (successful logon / valid Kerberos ticket); puts its own SID and group SIDs, including Analysts (RID 2701), in the system token.
2. u.arin makes an access request containing FILE_WRITE_DATA to write to file \\FS01\Reports\q3.xlsx.
3. Access check evaluates the file's DACL for token SIDs based on the write right requested.
4. DACL contains an allow ACE that gives only File Read/Execute to the Analysts group; There is no matching allow ACE for the write right.
5. When all ACEs are examined, the requested FILE_WRITE_DATA is still not provided; access is implicitly denied — even though the user is fully authenticated.
6. If the same user wanted to read the same file, access would be granted because a matching allow ACE for Read would be found; The decision is rights-based.

2. Exploitation

Broken trust assumption

Broken assumption: A valid credential/ticket or successful logon means access — 'I am authenticated, therefore I am authorized.' In reality, authentication only determines the identity and SIDs of the token; Each resource grants the requested right separately through its own DACL.

Technical prerequisites

• Synchronization of successful authentication (valid ticket, successful logon) with access permission; Omission or misinterpretation of per-resource, per-right access check.
• Resource DACLs grant over-broad rights to the token's group SIDs (over-broad ACE), so that the SIDs provided by authentication coincidentally carry authority.
• Authorization should be left at the 'is the user valid in the domain' level and not narrowed down to the object level.
• The impact of an exploit on the authentication side (stolen/misissued credential) is magnified when resource DACLs are large.

Exploitation mechanism

A valid identity is not a file right in this example. For an ordinary file request, the token’s SIDs match ACEs in the target DACL; unnecessarily broad ACEs increase the impact of an identity failure. Inventory resource rights and relevant token privileges as well as logon success. This Read/Write comparison assumes no enabled applicable bypass privilege; it does not reduce all Windows authorization to DACLs.

Token is a claim, not a key

The inference 'I have a valid account on the domain, therefore I can access this share' is false at the mechanism level. The valid account only determines which SIDs the token will carry; access depends on whether those SIDs find matching allow ACEs in the target resource's DACL. Therefore, an authentication success never proves an access check success on the relevant object.

A least-privilege DACL limits impact through this ordinary access path. You must also account for privilege-controlled paths such as backup/restore. A valid account and a security context able to perform this operation are different questions.

3. Defense & Detection

Telemetry scope

• 4624 records a successful logon session on the target host; it does not prove a file right was granted. Kerberos ticket events on a DC do not replace the resource access decision either.
• With Audit Detailed File Share enabled, 5145 provides evidence of a share-level access check. AccessMask and AccessList describe requested rights; AccessReason describes each right’s grant/deny result and relevant ACE rationale.
• Within the same host and boot scope, 4624.TargetLogonId = 5145.SubjectLogonId links the logon session to the share request. A share-level denial in 5145 shows that this request was denied despite successful logon; the NTFS outcome must be examined separately.
• 5145 Failure events are generated with an important constraint: the rejection occurs only at the file share level; Access denied at the NTFS (file system) level does not produce 5145 Failure, so absence does not mean 'not denied'.

Events and relevant fields

• 4624.TargetLogonId is the new session’s LUID. Match it to 5145.SubjectLogonId within the same host/boot scope; identical hexadecimal values on different hosts do not identify one session.
• 5145.AccessMask and AccessList/Accesses are request fields. AccessReason/Access Check Results carries the share-level result for a requested right and its relevant ACE. These fields do not contain the complete DACL or the NTFS decision.
• 5145's ShareName/RelativeTargetName fields give which share object was attempted; When the same token receives different results in different objects, these fields separate the per-resource decision.
• The presence of authentication events does not imply authorization; A correlation rule should interpret the pattern 'multiple successful authentications + repeated denied object access' according to the authentication/authorization distinction.

Read the two events separately but together

Separate the questions first: did authentication succeed, and was this operation accepted on this resource? 4624 helps with the first; 5145 helps with the second at share level. Link the session using 4624.TargetLogonId and 5145.SubjectLogonId within the same host and boot scope. Then examine ShareName, RelativeTargetName, requested rights and the AccessReason result.

A successful logon does not imply access was granted. A denial does not imply the identity was false. Even after a share check succeeds, NTFS can deny the request; that denial does not generate a 5145 Failure. When an event is absent, first ask about audit coverage and which layer made the decision.

Detection logic · Sigma

title: Share-level denial candidate from a single 5145 event
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5145
    AccessReason|contains: 'Access denied'
  condition: selection
fields:
  - SubjectUserSid
  - SubjectLogonId
  - ShareName
  - RelativeTargetName
  - AccessMask
  - AccessList
  - AccessReason
falsepositives:
  - Expected individual denials during normal access attempts
level: low

Query assumptions

• logsource windows/security and field names (AccessReason, AccessList, SubjectLogonId) assume SIEM flattens 5145 with these Data Names; The backend mapping must be verified.
• The rule selects share-level checks; an NTFS denial does not produce a 5145 Failure and is outside this selection.
• The 'Access denied' text is based on the denial indicator in AccessReason; In real distribution, the rejection may appear as a %%-encoded reason string rather than a constant message and must be adapted according to the mapping.
• This example selects individual 5145 candidate records only. It performs no 4624 join, repetition count or time-window calculation. Those require a collector with verified host/boot scope and field mapping; no Windows/SIEM execution is claimed.

False positives

• Users selecting the wrong share or requesting a file operation they are not allowed to perform can produce legitimate denials.
• Applications' probing of a resource may generate individual rejection events; A single incident does not indicate malicious intent.
• Normal workflows where Read is granted and Write is rejected (read-only shares) are expected rejections.
• The absence of the event may indicate not only that authorization is not working, but that the denial is at the NTFS level or that the Audit Detailed File Share subcategory is turned off.

Hardening

• Apply least-privilege DACLs to each resource; a valid domain identity alone must not imply broad access.
• For read-only needs, grant only Read rights; Link Write/Modify to separate, justified groups so that rights-based authorization is visible in the inventory.
• Enable Object access auditing (Audit Detailed File Share and Audit File System if necessary) on high value shares; Watch to know whether the rejections are only at the share or NTFS level.
• Measure noise and work impact on a pilot basis before implementing controls; Verify that least-privilege throttling does not break legitimate access and keep a fallback plan.

Read the examples

O:BAG:DUD:(A;;FRFX;;;S-1-5-21-1002233445-2244556677-3366778899-2701)(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-1002233445-2244556677-3366778899-513)

Two reality checks

Assumption: If I log in to the domain with a valid account (authenticate), I can access the shares and files.

In fact: Authentication only proves identity and determines which SIDs go into the access token. Being able to perform a particular operation on a file or share is a separate access control decision that depends on whether that object's DACL grants the requested right to the SIDs in the token. Therefore, a valid logon does not guarantee specific access to any object; The same identity can be authorized in one object and unauthorized in another.

Assumption: Having a valid Kerberos ticket grants full access to the resource to which that ticket belongs.

In fact: It covers the ticket authentication side: it proves identity and determines the token's group SIDs. Resource access is granted separately for the requested right by the security descriptor of the target object. Having a ticket answers the question 'who are you'; The DACL of each object answers the question 'can you do this on this object' according to the desired access mask. This example has no enabled applicable bypass privilege; privileges and other applicable checks are evaluated separately.

Sources

• Microsoft · Kerberos authentication overview
  Kerberos authentication proves identity; the ticket carries proof of identity, and resource authorization is a separate access check
• Microsoft · Access tokens
  The access token is the output of authentication; it carries user and group SIDs and is used in the access check
• Microsoft · How AccessCheck Works
  If there is no DACL, access is granted; ACEs are examined in order for the requested rights; access-denied denies, access-allowed entries grant all rights, otherwise implicit deny applies
• Microsoft · Access Rights and Access Masks
  Requested access mask; collecting generic and standard rights in the request mask, and the access check operating against that mask
• Microsoft · ACE strings
  SDDL ACE syntax; A (access-allowed) type and FR/FW/FX/FA file rights abbreviations
• Microsoft · 4624(S) An account was successfully logged on
  Successful logon (authentication evidence); correlation to later object access events with TargetLogonId
• Microsoft · 5145(S, F) A network share object was checked to see whether client can be granted desired access
  AccessMask/AccessList/AccessReason fields (right-based decision); Failure only when denied at the share level; Audit Detailed File Share
• Microsoft · Managing privileges in a file system
  Caller holds and enables privilege; SeBackupPrivilege/SeRestorePrivilege defined file operations, not a universal DACL-only outcome.