Authentication and Authorisation
Proving who you are, then deciding what you may reach, and where each is logged.
Why It Matters
Attackers want credentials because a valid account passes every check its owner passes and leaves the same events. Knowing which machine proves an identity and which grants access tells you where to look for each trace.
What Happens
A domain sign-in is proved by Kerberos or, where Kerberos cannot run, by the older NTLM, and the accounts behind it live on domain controllers. The topic page explains what each protocol is, why it exists and where it is still used, and this page covers what happens once an identity is proved. If these words are new, start with What a Domain Sign-In Is on the topic page.
Authentication proves who is asking, with a password, a key made from it, a ticket or a certificate. Authorisation then decides what that identity may reach, from the groups and privileges it carries. In a domain, a domain controller does the proving and the machine being reached does the deciding.
Once a sign-in succeeds, the machine that was reached builds an access token for the session. The token holds the account's security identifier (SID), the SIDs of its groups and its privileges. Every process the session starts carries a copy, and each access check compares it with the permissions on the object asked for.
A stolen account carries its owner's rights, so least privilege limits what a theft gives. Each account should hold only the rights its tasks need, and no day-to-day account should sit in Domain Admins. Marking privileged accounts "Account is sensitive and cannot be delegated" stops any server presenting their credentials to other machines.
Where a Sign-In Is Logged
A single domain sign-in leaves its trace on two machines, because the machine that holds the account proves the identity and the machine being reached grants the access. So one sign-in to a file server is checked on a domain controller and granted on the server, and each writes its own events. Windows files them under two audit categories. Account Logon is written where the account lives and answers who proved an identity, with which protocol and from which address. Logon/Logoff is written on the machine that was reached and answers who got in, how, from where, with which rights and for how long.
Every event in the table below is written to the Windows Security log, the proof events first and then the access events. Each one is written only while its audit subcategory is switched on, under Advanced Audit Policy Configuration in Group Policy, and the Switch It On column names that subcategory. One field inside event 4624 is worth reading on its own, the Impersonation Level, and the table after the events lists its four values.
| Event and Log | Written On | Switch It On | What It Tells You |
|---|---|---|---|
| 4776 The computer attempted to validate the credentials for an account (opens in a new tab) Security log | The computer that holds the account, a domain controller for a domain account or the computer itself for a local one | Audit Credential Validation | An NTLM sign-in was checked where the account lives. A pass-the-hash sign-in over NTLM shows here.NTLM Authenticate and Validation explains how to read it. |
| 4768 A Kerberos authentication ticket (TGT) was requested (opens in a new tab) Security log | Domain controllers | Audit Kerberos Authentication Service | A domain controller proved the account over Kerberos and issued a ticket-granting ticket (TGT), or refused one with a Result Code.AS Reply: The TGT explains how to read it. |
| 4769 A Kerberos service ticket was requested (opens in a new tab) Security log | Domain controllers | Audit Kerberos Service Ticket Operations | The account asked for a service ticket to reach one named service, and Service Name says which.TGS Reply: The Service Ticket explains how to read it. |
| 4771 Kerberos pre-authentication failed (opens in a new tab) Security log | Domain controllers | Audit Kerberos Authentication Service | A Kerberos sign-in was refused before a TGT was issued, such as for a wrong password (Failure Code 0x18).AS Request and Pre-Authentication explains how to read it. |
| 4624 An account was successfully logged on (opens in a new tab) Security log | The computer that was logged on to | Audit Logon | A session opened. Logon Type says what kind, Authentication Package says how it was proved (Kerberos, NTLM or Negotiate), and Impersonation Level says how far a server may act for the user.Reading Logon Events explains how to read it. |
| 4625 An account failed to log on (opens in a new tab) Security log | The computer where the logon was attempted | Audit Logon, and Audit Account Lockout for a locked-out account | A sign-in was refused, with the reason in Status and Sub Status.Reading Logon Events explains how to read it. |
| 4634 An account was logged off (opens in a new tab) Security log | The computer the session was on | Audit Logoff | The session ended. Its Logon ID matches the 4624 that opened it in the same log, though logoffs are not always written.Reading Logon Events explains how to read it. |
| 4647 User initiated logoff (opens in a new tab) Security log | The computer the user logged off from | Audit Logoff | The user chose to sign out, and a 4634 in the same log usually follows.Reading Logon Events explains how to read it. |
| 4672 Special privileges assigned to new logon (opens in a new tab) Security log | The computer that was logged on to | Audit Special Logon | The new session was given sensitive privileges, listed in Privileges. That is normal for an administrator and for SYSTEM, and a reason to look closer for anyone else.Reading Logon Events explains how to read it. |
| 4627 Group membership information (opens in a new tab) Security log | The computer that was logged on to, beside its 4624 | Audit Group Membership, with Audit Logon success on as well | The groups placed in the new session's token, which decide what it may open. Windows writes it only when Audit Logon is on as well. |
Impersonation Level in Event 4624
When you reach a server, a thread on it can borrow your identity to do work for you. The Impersonation Level in event 4624 in the Security log records how far it may take that identity. Delegation is the level to watch, because it lets the server act as you on other machines. That is what Kerberos delegation provides, and what an attacker abusing delegation is after.
| Impersonation Level | What the Server May Do with Your Identity |
|---|---|
| Anonymous | Nothing. It cannot identify you or act as you, and the event shows this level as an empty value. |
| Identification | Read your security identifiers (SIDs) and privileges, but not act as you. |
| Impersonation | Act as you on its own machine but not on others, the most common level. |
| Delegation | Act as you on other machines too. |
Check It on a Machine
These Windows Registry keys hold the settings this page names. Open one to see where it lives and how to read it on a machine.
Attacks That Hook in Here
These attacks work through what this page describes. Each card says what the attack is and, where it uses one of these steps, what it does there.
- Pass-the-Hash
Signs in over NTLM with a stolen NT hash, never needing the password.
- Pass-the-Ticket
Replays a Kerberos ticket copied from one machine's memory on another.
- Kerberos Delegation Abuse
Uses a server trusted for delegation to reach other services in users' names.
- Golden Ticket
Forges a TGT with the krbtgt key, for any account and groups, that every DC accepts.
- Active Directory Reconnaissance
Reads the directory in bulk to map accounts, groups, trusts and servers.
- AdminSDHolder and SID History
Two quiet ways to keep admin access, a template ACL or a SID in an account's history.
- Group Policy Abuse
A change to a policy many machines read, which reaches every one of them at once.
- Backdoor Accounts and Group Changes
Leaves an account behind, or adds one to a privileged group, as a quiet way back in.
Sources
- Microsoft Learn: Credentials Processes in Windows Authentication (opens in a new tab)
- Microsoft Learn: Access Tokens (opens in a new tab)
- Microsoft Learn: Impersonation Levels (opens in a new tab)
- Microsoft Learn: Security Event 4624 (opens in a new tab)
- Microsoft Learn: Audit Credential Validation (opens in a new tab)
- Microsoft Learn: Audit Kerberos Authentication Service (opens in a new tab)
- Microsoft Learn: Audit Kerberos Service Ticket Operations (opens in a new tab)
- Microsoft Learn: Audit Logon (opens in a new tab)
- Microsoft Learn: Audit Logoff (opens in a new tab)
- Microsoft Learn: Audit Special Logon (opens in a new tab)
- Microsoft Learn: Audit Group Membership (opens in a new tab)
- Microsoft Learn: Implementing Least-Privilege Administrative Models (opens in a new tab)
- MITRE ATT&CK T1078: Valid Accounts (opens in a new tab)