How Active Directory Sign-In Works

In a Windows domain, accounts do not live on each machine. They live on servers called domain controllers, and every machine in the domain trusts them to say who an account is. When you sign in, or reach a file share or another service, your machine and the server you are reaching both rely on a domain controller to prove your identity.

That proof uses one of two protocols, Kerberos or NTLM. Knowing which one ran, and what each one writes to the logs, tells an investigator where to look for the trace of a sign-in.

Kerberos is the protocol Windows uses by default to prove who an account is in a domain, and it works with tickets. When you sign in, a domain controller checks your identity once and gives your machine a ticket-granting ticket (TGT), a sealed note that says who you are. Your machine keeps the TGT and reuses it until it expires, so you are not asked for your password again.

To reach a service, such as a file server, your machine shows the TGT to the domain controller and asks for a service ticket for that one service. It then presents the service ticket to the server. The server can trust the ticket without calling the domain controller, because the domain controller sealed it with the server's own key, which only the two of them hold.

Kerberos fixes two weaknesses of NTLM, the older protocol described next. With NTLM a server has to ask a domain controller about every client that signs in, while a Kerberos ticket already carries what the server needs. NTLM also gives a client no way to check that the server is genuine, and Kerberos lets each side check the other.

Microsoft calls Kerberos version 5 the preferred way to sign in to Active Directory. The service that checks identities and issues the tickets is the key distribution centre (KDC). It runs on every domain controller and keeps its accounts in the Active Directory Domain Services database, so Kerberos needs Active Directory.

NTLM is the older family of protocols that Windows used before Kerberos, and it proves an account with a challenge and a response. The server sends a random challenge, and the client answers with a value computed from the account's password. The server checks the answer itself for a local account, or asks a domain controller to check it for a domain account.

NTLM has not gone away. Windows still uses it when Kerberos cannot run. That happens when a machine is in a workgroup instead of a domain, when the account is local to the machine, or when a program names the server by its IP address. Some applications also call NTLM directly.

The choice is usually made for you. A program that asks Windows for Negotiate gets Kerberos unless one of the machines cannot use it, or the program gave no name that Kerberos can use, such as a server's IP address. In those cases it gets NTLM.

Microsoft deprecated every version of NTLM in June 2024, which means it is no longer under active feature development, though it still works. Its version 1, NTLMv1, was removed starting with Windows 11 version 24H2 and Windows Server 2025. In January 2026 Microsoft said the next major Windows Server release and its client releases will block NTLM sign-ins across the network by default. New policy controls will let administrators turn them back on, and Microsoft gave no date.

Until then NTLM still appears in real sign-ins, so an investigator has to know both protocols and the different events each one leaves.

Read these three sections first, then step through the messages below one at a time. Each step shows what travels between the machines, which key seals it, what the receiver checks and what it writes to which log. The table under the window, Who Holds Which Key, says what each of those keys is made from and which machines hold it. Every page in the sidebar then explains one message or one idea in full.

The section Where a Sign-In Is Logged, on the Authentication and Authorisation page, gathers the sign-in events in one table, with the log each one lands in and the audit setting that switches it on.