Security Account Manager
The Security Account Manager (SAM), introduced in Windows NT, is a database component in Microsoft Windows operating systems that stores and manages local user accounts, security groups, and associated credentials, such as usernames and hashed passwords, to facilitate authentication and authorization for access to local resources.[1][2][3] SAM operates as a local account store on individual Windows devices, distinct from domain-based directories like Active Directory, and is responsible for creating default built-in accounts—such as Administrator and Guest—during the system's initial boot process.[2][1] These accounts are assigned unique Security Identifiers (SIDs) in the formatS-1-5-21-<ComputerIdentifier>-<Relative Identifier (RID)>, with predefined RIDs like 500 for Administrator and 503 for DefaultAccount, enabling precise control over permissions and rights on the local machine.[2]
Key aspects of SAM include its role in enforcing local security policies, such as user rights assignments and group memberships, which determine access to files, services, and system features without network dependencies.[1] For remote administration, the SAM Remote Protocol (MS-SAMR) provides a standardized interface for client-to-server communication, allowing IT administrators to query, create, modify, or delete user and group objects across networked Windows environments.[3] This protocol supports essential operations like enumeration of accounts and replication of security descriptors, ensuring consistent management in standalone or workgroup configurations.[3]
As a critical security element, SAM's database is protected by the Local Security Authority (LSA) subsystem, which manages authentication using hashed passwords, such as NTLM hashes, and protects the database through access controls, encryption, and auditing.[2][1] While primarily used in non-domain-joined scenarios, SAM integrates with broader Windows security models, underscoring its foundational importance in endpoint protection and identity management.[3]
Overview
Definition and Purpose
The Security Account Manager (SAM) is a database in Windows NT-family operating systems that stores local user accounts, groups, and security descriptors. It functions as a key component of the local security subsystem, maintaining the necessary information for identifying and authorizing users on a single computer. Introduced with Windows NT 3.1, the SAM replaced the legacy user files used in earlier systems like LAN Manager, providing a more integrated and secure method for handling local account data.[4] The primary purpose of the SAM is to enable local authentication, authorization, and management of non-domain user credentials on standalone or domain-joined systems. It supports essential functions such as verifying user identities during logon, assigning user rights to control access to system resources, and enforcing password policies for local accounts, including requirements for complexity and expiration. Passwords in the SAM are stored using hashing mechanisms to protect credential integrity, though specific details on these processes are addressed elsewhere.[5][6] Unlike Active Directory, which manages domain-wide accounts across networked environments, the SAM exclusively handles local accounts and is not used for domain authentication. This distinction ensures that local systems can operate independently for user management while integrating with broader domain structures when needed. On domain controllers, the SAM still exists but primarily serves local administrative functions, deferring domain account handling to Active Directory.[1][5]History
The Security Account Manager (SAM) was introduced with Windows NT 3.1 in 1993 as a core component of the NT security model, designed to enable secure local authentication in multi-user environments by storing user account information and hashed passwords in a protected database.[7] Prior to Windows NT, systems like LAN Manager relied on basic file-based mechanisms for account validation, but this lacked the robust, centralized database structure of SAM, which integrated with the NTFS file system for enhanced access controls. SAM evolved through subsequent releases, including Windows 2000, XP, and Server editions, where it became tightly integrated with the NTLM authentication protocol to support both local and domain-based logons.[8] In Windows NT 4.0 Service Pack 3 (1997), Microsoft added SYSKEY functionality to encrypt the SAM database using a system-generated key, providing additional protection against offline attacks by requiring the key for decryption.[9] Windows 2000 further advanced this by making NTLMv2 the default (available since NT 4.0 SP4) and prioritizing Kerberos for domain authentication, reducing reliance on weaker LM hashes while maintaining backward compatibility for local accounts.[10] Significant security enhancements occurred starting with Windows Vista in 2007, when Microsoft deprecated storage of LM hashes by default due to their vulnerability to cracking attacks, shifting focus to stronger NTLMv2 and Kerberos mechanisms in domain contexts.[11] Full removal of LM hash support followed in Windows 10 and 11, eliminating legacy storage entirely upon password changes and enforcing modern hashing to mitigate offline extraction risks.[12] Key milestones include Microsoft's response to vulnerabilities via security bulletins, such as adaptations for compatibility with older systems through tools like the Diagnostics and Recovery Toolset (DaRT), which allows password resets by accessing the SAM database in recovery environments.[13] Post-2010, hardening efforts emphasized protections against offline attacks, including mandatory stronger encryption and policy restrictions on legacy protocols, ensuring SAM's resilience in contemporary Windows ecosystems.[14]Technical Architecture
Storage and Location
The Security Account Manager (SAM) database is stored as a registry hive at HKEY_LOCAL_MACHINE\SAM within the Windows registry, with its underlying data persisted in the binary file located at %SystemRoot%\System32\config\SAM, along with supporting files such as SAM.log for transaction logging and SAM.sav as a backup copy.[15][16] The related SECURITY hive, which contains security policies and complements SAM functionality, resides at HKEY_LOCAL_MACHINE\SECURITY and is backed by the file %SystemRoot%\System32\config\SECURITY, including its own .log and .sav files.[15][16] These hives follow the standard Windows registry file format, consisting of a base block header followed by allocated bins of 4 KB each to accommodate data growth.[15] During system boot, the Windows kernel's Configuration Manager loads the SAM hive into memory. The Local Security Authority Subsystem Service (LSASS.exe) then initializes local authentication services using the loaded data for credential validation without direct file access thereafter.[17][18] Once loaded, the SAM file becomes locked by the operating system to prevent runtime modifications or extractions, ensuring integrity during active sessions.[19] Access to the SAM hive requires elevated privileges, specifically the SYSTEM account, as standard administrative access is insufficient for reading or modifying its protected subkeys; tools like Registry Editor (regedit.exe) can view it in read-only mode only under these conditions.[16][19] For recovery purposes, the Volume Shadow Copy Service (VSS) enables creation of point-in-time snapshots of the system volume, allowing access to previous versions of the SAM file even when locked, which facilitates restoration in scenarios like data corruption.[20] Additionally, offline copies of the SAM hive can be loaded and edited in environments such as Windows Recovery Environment (WinRE), where regedit can mount the file from a non-booted installation for repair tasks.[21] The typical size of the SAM hive file ranges from approximately 262 KB in minimal configurations to several megabytes, scaling with the number of local user accounts and associated security data.[22]Data Structure and Components
The Security Account Manager (SAM) database employs a binary registry hive format, consisting of a header followed by fixed-size HBIN blocks (typically 4 KB each) that contain variable-sized CELLs for storing keys, values, and lists.[23] The hive header includes a signature ("regf"), modification timestamps, version information, and offsets to the root key and data blocks, ensuring structural integrity during reads and writes.[23] This layout allows for efficient hierarchical organization, with the SAM mounted under HKEY_LOCAL_MACHINE\SAM in the Windows registry.[24] At the core of the SAM structure is a domain-centric hierarchy, treating the local machine as the primary domain under the root key \SAM\Domains.[23] User accounts reside in \SAM\Domains[Account](/page/Account)\Users, where each subkey is named after the user's Relative Identifier (RID), a 32-bit value appended to the machine's domain Security Identifier (SID) for unique identification.[25] For example, the built-in Administrator account uses RID 500, resulting in a full SID like S-1-5-21-Authentication and Management
Password Storage Mechanisms
The Security Account Manager (SAM) processes passwords by converting them into hashed representations to avoid storing plaintext values, ensuring that credentials remain protected even if the database is accessed. The primary hashing method used is the NT hash, which applies the MD4 algorithm to the Unicode representation of the password, resulting in a 128-bit (16-byte) value. This unsalted hash is computed directly from the password without additional randomization, a design choice that simplifies authentication but introduces risks if the hash is extracted.[28][29] Historically, SAM also supported the legacy LAN Manager (LM) hash, a weaker mechanism introduced in earlier Windows versions for compatibility with older systems. The LM hash processes the password by converting it to uppercase, truncating or padding it to 14 characters, splitting it into two 7-character halves, and encrypting each half using the Data Encryption Standard (DES) algorithm with a fixed key derived from the characters. This produces two 8-byte DES-encrypted blocks concatenated into a 16-byte hash, which is case-insensitive and limited to 14 characters due to its design constraints. The LM hash has been deprecated and is disabled by default since Windows Vista SP1 and Windows Server 2008, with modern systems configured via the NoLMHash registry setting to prevent its storage.[12][30] These hashes are stored within individual user objects in the SAM database, specifically under the variable-length "V" value in the registry structure of the SAM hive, where the NT hash occupies a fixed offset and the LM hash (if enabled) follows. No plaintext passwords are ever retained in SAM; instead, only these one-way hashes are persisted to support verification during authentication. To enforce password reuse prevention, SAM maintains a history of up to 24 previous password hashes per user account, configurable via the "Enforce password history" policy, allowing the system to reject passwords matching any stored prior hashes.[31][32] Over time, password storage in SAM has evolved to integrate with enhanced authentication protocols. The NT hash serves as the foundation for NTLM (NT LAN Manager) protocols, where NTLMv1 provides basic challenge-response authentication using the hash to derive responses to server challenges, while NTLMv2 improves security by incorporating stronger session keys, timestamps, and client challenges to mitigate replay and man-in-the-middle attacks. Beginning with Windows 10 and Server 2016, SAM benefits from Credential Guard, a virtualization-based security feature that isolates sensitive credential data—including NT hashes from LSASS (Local Security Authority Subsystem Service)—in a secure kernel enclave, preventing unauthorized access by malicious processes even if they escalate privileges.[33][34] A core aspect of SAM's password mechanisms is the absence of salting in NT hashing, meaning identical passwords always yield the same hash value across accounts, which facilitates offline verification but also enables precomputed attacks if hashes are compromised. Additionally, SAM enforces local password policies, such as the "Password must meet complexity requirements" policy, which requires passwords to not contain the user's account name or full name and to include characters from at least three of the following four categories: uppercase letters, lowercase letters, base-10 digits, and non-alphabetic characters (e.g., symbols); the minimum password length is enforced by a separate policy with a default of 0 characters (often configured to 6-14 characters). These policies are stored as domain properties in the SAM database and applied during password changes via APIs like SamQueryInformationDomain. These policies ensure standardized security without relying on domain controllers for local accounts.[29][28][35][36]Local Account Handling
The Security Account Manager (SAM) facilitates the creation of local user accounts through Windows APIs such as NetUserAdd, which adds a new user entry to the SAM database along with specified attributes like username and privilege level.[37] Upon creation, these accounts are automatically assigned to default local groups, such as the Users group for standard accounts or the Guests group for guest accounts, ensuring appropriate baseline permissions without manual group assignment.[38] Account deletion is handled via complementary APIs like NetUserDel, which removes the user entry from the SAM database while preserving any associated group memberships for cleanup if needed.[38] SAM supports key operational features for local accounts, including logon tracking that records the last successful logon timestamp and the number of failed logon attempts to aid in security monitoring and lockout enforcement.[18] Account expiration policies can be configured per user, specifying a date after which the account becomes inactive, typically set through management tools to enforce temporary access.[2] Additionally, functions to disable or enable accounts are available, allowing administrators to temporarily suspend access without deletion, such as marking an account as inactive to prevent logons while retaining its data in SAM.[2] SAM integrates closely with the Local Security Authority (LSA) subsystem, where LSA queries SAM during local authentication to validate user credentials and retrieve account details for session initialization.[18] This integration extends to built-in accounts like the Administrator, which holds elevated privileges for system management, and the Guest account, designed for limited, anonymous access and often disabled by default for security reasons.[2] Local accounts in SAM are managed through various tools, including the command-line utility net user for operations like adding, modifying, or querying accounts (e.g., net user username /add).[2] The graphical user interface tool lusrmgr.msc, accessible via Computer Management, provides a console for viewing, creating, and editing local users and groups in a structured tree view.[39] PowerShell cmdlets from the LocalAccounts module, such as New-LocalUser for creation and Get-LocalUser for querying, enable scripted automation of SAM data modifications on Windows systems.[40] SAM enforces a limit of 20 characters for local usernames to maintain compatibility with legacy systems and protocols, truncating longer names if necessary during account setup.[41] In mixed environments with both local and domain accounts, SAM maintains domain isolation by restricting local accounts to the machine's SAM database, preventing direct overlap or authentication conflicts with Active Directory domain accounts unless explicitly bridged via trust relationships or cached credentials.[18][1]Security Protections
Access Controls
The Security Account Manager (SAM) hive in the Windows registry is safeguarded by discretionary access control lists (DACLs) that restrict modifications to highly privileged entities. Specifically, full control over the SAM hive, located at HKEY_LOCAL_MACHINE\SAM, is granted exclusively to the Administrators group and the SYSTEM account, preventing standard users or lower-privileged processes from altering user account data or password hashes stored within it. However, in Windows 10 versions 1809 to 20H2, the Users group was granted read access, as highlighted in a security analysis. In response to CVE-2021-36934 (HiveNightmare), Microsoft updated permissions in subsequent builds (e.g., via KB5005565 for version 1809 and later patches) to deny read access to the SAM hive for standard users, restoring restrictions to privileged entities only.[42][43] This permission model ensures that only elevated administrative actions can interact with SAM contents during runtime, thereby mitigating unauthorized tampering with local security principals. Runtime protections further enforce isolation of SAM data through the Local Security Authority Subsystem Service (LSASS.exe), which loads the SAM database into protected memory spaces inaccessible to non-privileged processes. This process isolation denies direct registry access to applications lacking sufficient privileges, as LSASS operates as a protected process that shields sensitive credential information from memory scraping or injection attacks by untrusted code. On Windows 8.1 and later versions, additional LSA protections explicitly block non-protected processes from reading LSASS memory or injecting code, enhancing the integrity of SAM-loaded data during active sessions.[44] Auditing mechanisms provide oversight for SAM modifications via Windows Security Audit policies, logging events such as user account creations under Event ID 4720 in the Security log. This event captures details like the new account's security identifier (SID), the responsible subject's account, and the target domain, enabling administrators to track changes to local SAM accounts on domain controllers, member servers, and workstations. Such logging is activated through the "Audit User Account Management" policy in Group Policy, ensuring traceability without compromising performance.[45] Accessing SAM data, particularly for offline analysis, requires specific user rights assignments like SeBackupPrivilege or SeRestorePrivilege, which bypass standard ACL checks to allow backup and restoration of registry hives including SAM. These privileges enable tools to retrieve file contents even when DACLs would otherwise deny access, but they are typically reserved for backup operators or administrators performing maintenance tasks. For online management of SAM, such as creating or modifying local accounts, User Account Control (UAC) mandates elevation to full administrative privileges, prompting for credentials to prevent inadvertent or malicious alterations by standard users.[46] These access controls originated with the introduction of enhanced ACL support in Windows NT 4.0, building on the foundational security model of earlier NT versions to provide granular permissions over registry objects like the SAM hive. In Windows 10 and later, AppLocker extends these protections by allowing administrators to define execution policies that restrict unauthorized applications from interacting with LSASS, thereby limiting potential vectors for SAM data exfiltration through controlled software whitelisting.[47][48]Encryption and Integrity Measures
The Security Account Manager (SAM) employs encryption to obfuscate sensitive data within its registry hive, primarily using a boot key derived from values stored in the SYSTEM hive at locations such asHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\JD, Skew1, GBG, and Data. This boot key serves as the foundation for decrypting the SAM\Domains\Account section, where local user password hashes are stored, preventing straightforward offline access to these hashes. In earlier implementations, the SysKey utility enhanced this protection by optionally requiring a startup password or storing the encryption key on removable media, thereby further scrambling the boot key and making unauthorized decryption more challenging. SysKey was removed in Windows 10 version 1709 and later versions, including Windows 11, as it could be exploited by attackers.[49][9][50][51]
In modern Windows versions, the encryption mechanism integrates elements of the Data Protection API (DPAPI) for protecting related system secrets, though the core SAM obfuscation remains tied to the boot key derivation process. The boot key itself is regenerated when SysKey is enabled or modified, ensuring that any prior key configurations become invalid and requiring re-authentication for access. This rotation mechanism ties directly to changes in system security settings, maintaining the integrity of the encryption over time. Additionally, the Local Security Authority Subsystem Service (LSASS) leverages LSA secrets—stored in the SECURITY hive and encrypted with an LSA key derived from the same boot key—for session key management during user authentication and policy enforcement.[52][53][18]
Integrity measures for the SAM hive include built-in checksum validation within the registry hive file headers, which detect corruption or tampering during loading; if the checksum fails, Windows logs an error and may require manual recovery using backups or repair tools.[54][55] For broader protection, integration with BitLocker full-volume encryption ensures that SAM files, located in %SystemRoot%\System32\Config, are safeguarded at the disk level, rendering the hive inaccessible without proper decryption of the entire volume using AES algorithms.[56]
A key evolution in encryption strength occurred with Windows 8, where related LSA secrets adopted AES-256 for enhanced confidentiality, surpassing earlier RC4-based methods and aligning with stronger cryptographic standards for system-wide protections. Notably, while the containing structures in the SAM are encrypted, there is no end-to-end encryption applied to the password hashes themselves, which remain in hashed form (such as NTLM) within the protected blocks to facilitate authentication without exposing plaintext equivalents.[57][58]