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. 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 protocols.
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).Resilient Logon Solution
Furthermore, 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 unavailable.
Note: You can check in the security log, what kind of logon type you used. Each logon type has its own number. However, 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.
Moreover, Through the registry and a resource kit utility (Regkey.exe), you can change the number of previous logon attempts a server will cache. The valid range of values for this parameter is 0 to 50. In addition, 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.
Nonetheless, This will Open the Registry Editor, as shown below. Navigate through the following 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. Double-click the “Interactive logon: Number of previous logons to cache” policy to configure it as needed when the domain controller is unavailable.
What is Windows Logon Cached Password Verifiers?
These verifiers, not credentials, can’t be presented for remote authentication. They validate credentials locally, stored in the local computer’s registry, when AD DS connection isn’t possible during logon. These “cached logons” or more
Manage cached domain account info with the security policy setting “Interactive logon: Number of previous logons to cache” when the domain controller isn’t 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: A user signing into a Windows computer provides a plaintext username and credential information. The user’s identity authentication protocol requires converting the plaintext password, and some Windows versions retain an encrypted copy for authentication methods like 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 holds all computer-specific credentials, including the built-in local Administrator account and other local accounts.
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: LSASS stores credentials in memory for Windows users with active sessions. Furthermore, Users can access network resources like file shares, Exchange Server mailboxes, and SharePoint sites seamlessly. You do it without re-entering 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
LSASS stores the account’s NT hash value and the smart card’s plaintext PIN when the user logs onto Windows with a smart card, not a plaintext password. Enable the account attribute for a required smart card. It will automatically generate a random NT hash value instead of the original password hash. The password hash 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.
