Skip to content

LSA 3: Describe Local Login

Understanding Local Logon in Windows

Local Logon is the process by which a user authenticates to a specific computer using credentials that are stored locally on that machine. Unlike domain logons, which rely on a networked domain controller for authentication, local logons are confined to the system’s own user accounts and do not require a connection to a network or domain. This is typical for standalone machines or for local administrative accounts on computers within a domain.

Key Components of Local Logon

Local Account

A local account refers to a user account whose credentials are stored directly on the local machine. These credentials, which typically consist of a username and password, are stored in the Security Accounts Manager (SAM) database, a specialized database within Windows that maintains user account information for systems that are not part of a domain. The SAM database contains a list of all local users and their hashed passwords.

Local accounts are typically used on individual, non-domain-joined computers, and each local account is tied to a single machine. The credentials stored in the SAM are only valid on the machine where they were created. This means that if a user has a local account on multiple systems, they will need to authenticate separately to each one, using the different credentials for each machine.

The Logon Process

  1. User Credential Entry: The logon process begins when the user attempts to log in by entering their username and password at the logon screen of the computer. This is typically the first interaction with the system, where the user is prompted to supply their credentials.

  2. Credential Validation by the Local Security Authority (LSA): Once the user submits their credentials, the Local Security Authority (LSA), which is a core component of Windows responsible for enforcing security policies, takes over the validation process. The LSA checks the submitted username and password against the credentials stored in the SAM database.

  3. If the username and password match an existing entry in the SAM database, the LSA successfully authenticates the user.

  4. If the credentials are incorrect, the logon attempt fails, and the user is typically given a set number of attempts to re-enter the correct information.

  5. Access Granted: Upon successful validation of the credentials, the user is granted access to the system. At this point, the system generates an access token for the user, which contains information about the user’s identity, group memberships, and the permissions they are authorized to have on the local system.

The user is then allowed to interact with the operating system and access resources according to their assigned permissions. This includes access to files, applications, and system settings that are available to their user account.

  1. User Session Initiated: Once authentication is successful, the user's desktop environment is loaded, and a session is created for the user. This session is active until the user logs off or shuts down the system.

Key Concepts in Local Logon

SAM Database (Security Accounts Manager):

The SAM database is a critical component for local logons. It stores the usernames, passwords (in a hashed format), and other essential account information for local accounts on the computer. The SAM is accessible only to system-level processes, and it is protected by various security measures to prevent unauthorized access.

When a user logs on with a local account, the system consults the SAM database to authenticate the user's credentials. If the credentials match the stored information, the user is allowed access to the system.

Local Security Authority (LSA):

The Local Security Authority (LSA) is responsible for enforcing the security policy of the operating system. It validates user credentials, manages local security settings, and issues access tokens for authenticated users. The LSA interacts directly with the SAM database to perform authentication in the case of local logons.

Access Tokens:

After successful authentication, the operating system generates an access token for the user. This token contains the user's Security Identifier (SID) and the user's associated group memberships and privileges. The access token is used by the system to determine the user’s access rights for files, applications, and other resources on the machine.

Access tokens ensure that the system can enforce security policies by validating user rights and controlling access to sensitive resources.

Use Cases for Local Logon

  • Standalone Computers: Local logon is often used on computers that are not part of a network domain. This includes personal devices, workstations in smaller businesses, or systems used for specific tasks that do not need network access.

  • Local Administrator Accounts: Many systems have local administrator accounts that are used for system configuration, troubleshooting, and maintenance. These accounts often have elevated permissions and are used to perform tasks that require administrative privileges.

  • Offline Logon: Local logon is useful when a system is not connected to a network or domain, such as when a laptop is taken offline or when the machine is unable to reach a domain controller. In these cases, authentication is still possible via the SAM database.

Advantages and Limitations of Local Logon

Advantages:

  1. Simplicity: Local logon is straightforward and does not require any network infrastructure, making it easy to set up and use on individual machines.
  2. Offline Access: Local logon allows users to access their systems even when they are not connected to a network, providing more flexibility in certain environments.
  3. Enhanced Security in Isolated Systems: For systems that do not require network access, local logon can provide a more secure environment because the system is not reliant on external network-based authentication mechanisms.

Limitations:

  1. Limited to One Machine: Local accounts are confined to the machine where they are created. Unlike domain accounts, they cannot be used to access other computers or resources on a network.
  2. Lack of Centralized Management: Without a domain, administrators must manage user accounts and permissions individually on each machine. This can become cumbersome in larger environments where centralized control is desired.
  3. Security Risk: Local accounts, particularly those with administrative privileges, can be vulnerable if not properly managed. If a local account's password is weak or compromised, an attacker could gain full access to the system.

Conclusion

The local logon process is an essential method of authenticating users on standalone or non-domain-joined Windows computers. By relying on the SAM database and the Local Security Authority (LSA), Windows ensures that only users with valid credentials can access the system. While local logons are ideal for personal computers or small isolated systems, they are less scalable than domain-based logons, which offer centralized management and broader network access. Nonetheless, local logon remains an important authentication mechanism in many use cases, especially for individual devices and administrative accounts.

Steps in the Local Logon Process:

  1. CTRL+ALT+DEL (Secure Attention Sequence - SAS): The process begins when the user presses CTRL+ALT+DEL on the keyboard. This key combination, known as the Secure Attention Sequence (SAS), is a security measure that signals to the operating system that the user is attempting to log on. The SAS ensures that the logon prompt is not spoofed by any malicious software running in the background.

  2. Winlogon and LogonUI Initiation: After receiving the SAS, the Winlogon process takes control of the logon sequence. Winlogon is a critical system process that handles user logons, among other responsibilities. It then starts two key processes: LogonUI and Userinit.

    • LogonUI is the graphical logon interface that presents the user with a prompt to enter their credentials (usually username and password).

    • Userinit is responsible for initializing the user's environment once they have successfully logged in.

  3. User Credentials Input: In this step, the user enters their username and password into the LogonUI interface. After the user submits their credentials, LogonUI collects this information and passes it to the Local Security Authority (LSA) for validation. LogonUI then exits the logon process, leaving the LSA to handle authentication.

  4. Credential Validation via LSA and Msv1_0.dll: The Local Security Authority (LSA) is responsible for enforcing security policies and managing authentication. The LSA uses the Msv1_0.dll file, an authentication package used by Microsoft to verify the credentials against the information stored in the SAM (Security Accounts Manager) database. The SAM contains hashed passwords and other account information for local user accounts.

    • If the credentials are valid, the user is authenticated and granted access.

    • If the credentials are invalid, the logon attempt fails, and the user is prompted to try again.

  5. Access Token and Explorer.exe Launch: After the user is authenticated, the system creates an access token that contains the user’s identity, privileges, and group memberships. This token is necessary for determining what resources and system functions the user can access.

    • The process Userinit.exe then launches explorer.exe, which is the graphical user interface (GUI) for Windows, and the user’s desktop environment is presented.

    • The access token is passed to explorer.exe, giving the user the appropriate access rights to system resources. Once explorer.exe is launched and the user’s session is active, Userinit.exe exits.

At this point, the user has successfully logged into the local machine, and their desktop environment is ready to be used. Any interaction with the system will be governed by the permissions associated with the user’s access token.