What is LSASS - Part 2

Keeping it simple: LSASS (Local Security Authority Subsystem Service) handles user authentication (access to the domain via the Domain Controller (DC) or locally using the Security Access Manager (SAM) table) and enforces security policies.  If you haven’t read it, check out the first write-up: SOC Analyst Perspective LSASS - Importance in Active Directory Attacks Part 1

Domain Authentication (against the domain controller) — NTLM authentication

Let’s go over a machine that is domain-joined. Now, I kind of skipped ahead, but bear with me —  LSASS is a part of the concept called Local Security Authority (LSA). LSA supports authentication activities and enforces security policies. Think of LSA as the car, and LSASS is the engine that powers it. Refer to the Microsoft Interactive Logon documentation for a more in-depth explanation.

LSASS uses authentication packages to validate credentials; an authentication package is a Dynamic Link Library (DLL). MSV1_0 is responsible for managing interactive logons. For local authentication, LSASS uses the MSV1_0 package. For domain authentication, LSASS also uses the same MSV1_0 package for NTLM authentication, specifically. NTLM is no longer the preferred method due to security reasons.

A service called NetLogon is responsible for managing the conversation between the requesting machine and the domain controller by passing off the credentials the user inputs to the domain controller for validation against the Active Directory database. The result is returned to the MSV1_0 package on the requesting machine.

Refer to the Windows Authentication documentation by Microsoft for more information.

Domain Authentication (against the domain controller) — Kerberos authentication

Now, writing this back, I forgot to mention (shame on me) important background information:

Kerberos was invented back in the 1980s at MIT and was released as open source in 1987. It is now the standard for domain login.

Microsoft is actively moving away from the older NTLMv1 protocol in favor of Kerberos as the standard for authentication. For example, in Windows 11 version 24H2 and Windows Server 2025, NTLMv1 support has been removed from the listed devices. We’ll have to dive into the why in another article. For context, note that the NTLM protocol is the weaker of the two.

The use of which authentication package will depend on what the domain has configured (e.g., Domain Controller only allows authentication via Kerberos)

The Kerberos authentication package (kerberos.dll) supports the Kerberos authentication protocol, which supports user authentication for service access. Kerberos uses tickets as proof of identity.

Here are some questions to think about:

• What happens to the user input now that we have tickets instead of usernames + hashed passwords being passed?

This again requires a deeper dive into what Kerberos is and the creation of a ticket.

I would suggest reading to understand how a request is sent and responded to; consider Kerberos Explained in a Little Too Much Detail by Steve Syfuhs.

Overall, LSASS will opt for the Kerberos authentication package (kerberos.dll) instead of the MSV1_0 package for NTLM authentication.

Remember the scenario: a user has now input a username and password.

I don’t want to delve into the details of how Kerberos works repeatedly, but I want to note that the LSASS derives a cryptographic key from the user’s password. That cryptographic key is a part of the authentication request to the domain controller for a TGT.

I’ll try to write further about this another day!