This article discusses how credentials are formed in Windows and how they are being consumed by the Operating System. Before proceeding, let us discuss some key terms. If a user or service wants to access a computing resource, they must provide information that proves their identity. This identity is typically in the form of their account’s user name. This might be the user name that is the Security Accounts Manager (SAM) account name or the User Principal Name (UPN). But to prove their identity, they must provide secret information, which is called the authenticator. An authenticator can take various forms depending on the authentication protocol and method. The combination of an identity and an authenticator is called an authentication credential. The process of creating, submitting, and verifying credentials is described simply as authentication, which is implemented through various authentication protocols, such as the Kerberos, NTLM, TACACSs+, and RADIUS protocol. You may also want to visit the following interesting articles. What are the merits and demerits of Local System Account and Service Logon Account, how to delete and restore objects using Active Directory Administrative Center, and what are the differences between an Active Directory contact and a user account object?
Authentication establishes the identity of the user, but not responsible for the Authorization. depending on the protocol used, this can be defined at a later stage and this is referred to as Authorization. Credentials are created or converted to a form that is required by the authentication protocols that are available on a device and these credentials can be stored in the Local Security Authority Subsystem Service (LSASS) process memory for use by the account during a session. Credentials must also be stored on a hard disk drive in authoritative databases, such as the SAM database and in the database that is used by Active Directory Domain Services (AD DS).Cached credentials also known as cached logon data are a piece of information that a user uses to logon into a corporate network when the domain controller is not available.
Note: You can check in the security log, what kind of logon type you used. Each logon type has its own number. If you are interested, then you can always search the MSDN for the logon type and you’re going to find appropriate information.
When you log on to Windows by using cached logon information, if the domain controller is unavailable to validate your account, you cannot access network resources that require domain validation. However, you can access network resources that do not require domain validation.
Through the registry and a resource kit utility (Regkey.exe), you can change the number of previous logon attempts that a server will cache. The valid range of values for this parameter is 0 to 50. A value of 0 turns off logon caching and any value above 50 will only cache 50 logon attempts. By default, all versions of Windows remember 10 cached logons except Windows Server 2008. For more on Windows Registry, see the following link.
Cached login information is controlled by the following Registry keys below or Group Policy Objects:
– Via The Windows Registry: follow the steps below to launch the registry editor. From the Windows search box, type “regedit.exe” to launch the Windows Registry Editor as shown below.
This will Open the Registry Editor as shown below. Navigate through the follow hive and find the “winlogon” key.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current
Version\Winlogon\
- Value name: CachedLogonsCount
- Data type: REG_SZ
- Values: 0 - 50
Any changes you make to this key require that you restart the computer for the changes to take effect– Via Group Policy: You can find an item called “Interactive logon: Number of previous logons to cache and this can be configured to suit our need in case the domain controller is not available”. Lunch Group Policy by using the Windows Search, type “gpedit.msc” as shown below For more on Group policies, kindly see the following link1 and link2.
This will open the Group Policy Editor, navigate thorough the following "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\"
In this policy setting, a value of 0 disables logon caching. Any value above 50 only caches 50 logon attempts. Default number: 10. See the images below for more information. To get here, double click on the policy “Interactive logon: Number of previous logons to cache and this can be configured to suit our need in case the domain controller is not available”.
What is Windows Logon Cached Password Verifiers?
These verifiers are not credentials because they cannot be presented to another computer for authentication, and they can only be used to locally verify a credential. They are stored in the registry on the local computer and provide credentials validation when a domain-joined computer cannot connect to AD DS during a user’s logon. These “cached logons” or more
specifically, cached domain account information can be managed using the security policy setting Interactive logon: Number of previous logons to cache (in case the domain controller is not available).
What are the various forms of Credential Authenticators?
1: NT hash: The NT hash of the password is calculated by using an unsalted MD4 hash algorithm. MD4 is a cryptographic one-way function which produces a mathematical representation of a password. This hashing function is designed to always produce the same result from the same password input, and to minimize collisions where two different passwords can produce the same result. This hash is always the same length and cannot be directly decrypted to reveal the plaintext password. Because the NT hash only changes when the password changes, an NT hash is valid for authentication until a user’s password is changed.
Note: To protect against brute-force attacks on the NT hashes or online systems, users who authenticate with passwords should set strong passwords or passphrases that include characters from multiple sets and are as long as the user can easily remember
2: Plaintext Credentials: When a user signs in to a computer running Windows and provides a user name and credentials (such as a password or PIN), the information is provided to the computer in plaintext. This plaintext password is used to authenticate the user’s identity by converting it into the form that is required by the authentication protocol. Some versions of Windows also retain an encrypted copy of this password that can be unencrypted to plaintext for use with authentication methods such as Digest authentication.
Note: Windows operating systems never store any plaintext credentials in memory or on the hard disk drive. Only reversibly encrypted credentials are stored there. When later access to the plaintext forms of the credentials is required, Windows stores the passwords in an encrypted form that can only be decrypted by the operating system to provide access in authorized circumstances.
3: LM Hash: LAN Manager (LM) hashes are derived from the user password. Legacy support for LM hashes and the LAN Manager authentication protocol remains in the NTLM protocol suite. Default configurations in Windows and Microsoft
security guidance have discouraged its use.
LM hashes inherently are more vulnerable to attacks because:
– LM hashes require a password to be less than 15 characters long and they contain only ASCII characters.
– LM hashes do not differentiate between uppercase and lowercase letters.
Where are Windows credentials stored? I will be emphasizing more on how credentials are stored in Window Operating
System (OS). Windows credentials are composed of a combination of an account name and the authenticator. These are stored and retrieved from the following locations depending on the status of the user’s session, which
might be active or inactive, and local or networked.
1: Security Accounts Manager (SAM) database: The SAM database is stored as a file on the local hard disk drive, and it is
the authoritative credential store for local accounts on each Windows computer. This database contains all the credentials that are local to that specific computer, including the built-in local Administrator account and any other local accounts for that computer.
The SAM database stores information on each account, including the user name and the NT password hash. By default, the SAM database does not store LM hashes on current versions of Windows. No password is ever stored in a SAM database—only the password hashes. The NT password hash is an unsalted MD4 hash of the account’s password. This means that if two accounts use an identical password, they will also have an identical NT password hash.
2: LSASS process memory: The Local Security Authority Subsystem Service (LSASS) stores credentials in memory on behalf of users with active Windows sessions. This allows users to seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.
LSASS can store credentials in multiple forms, including:
– Reversibly encrypted plaintext
– Kerberos tickets (TGTs, service tickets)
– NT hash
– LM hash
If the user logs on to Windows by using a smart card, LSASS will not store a plaintext password, but it will store the corresponding NT hash value for the account and the plaintext PIN for the smart card. If the account attribute is enabled for a smart card that is required for interactive logon, a random NT hash value is automatically generated for the account
instead of the original password hash. The password hash that is automatically generated when the attribute is set does not change.
If a user logs on to Windows with a password that is compatible with LM hashes, this authenticator will be present in memory. The storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require them are disabled.
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.
