The process of a user logging on to a computer and accessing local or network resources is made up of many individual components, including an identity, authentication, access control, authorization, and auditing.
Identity
Both computers and users have logon accounts and passwords in Active Directory. Both require unique logon names, and a password (or some other form of unique authentication, such as a smart card or biometric result). The user or computer account name must be unique in the namespace (i.e. Security Account Manager or Active Directory database) it is attempting to authenticate and log on to successfully. In computer security circles, the unique logon account is called an identity.
| Note |
In Vista, security principals can authenticate themselves with a wide range of authentication methods, including passwords, smart cards, and biometric identification devices. In this chapter, whenever the word "password" is used, it should be understood to stand for any sort of valid supplied authentication credential. The word "password" is being used to make the overall concepts easier to understand.
|
To be completely accurate, two security principals can share the same logon or display name, but the entire name path (called absolute path) in the authentication database or directory service must be unique. Hence, there can be two rgrimes in Active Directory, but only one rgrimes in a particular organizational unit location. The following examples would be valid in the same authentication database:
\Washington\Users\rgrimes and \Virginia\Users\rgrimes
A single user, or for that matter any Windows object, can appear only once in a directory structure. The same rgrimes cannot appear in the two places at once. If there are two rgrimes accounts in the same directory service, they are not the same object.
Authentication
When the user or computer supplies the correct password, the security principal is considered authenticated. If using the Kerberos authentication protocol (covered shortly), the authenticated user or computer should not need to supply its password again, if it keeps the same token for the next 10 hours to participating domain resources. And even after 10 hours, the computer will usually authenticate the user automatically using the credential supplied during the original logon.
Computer Accounts
After a computer boots up and loads Windows, it logs on to Active Directory with a logon name and password. The computer's account name is its host-name (for example, LabPC1) followed by a $ (for example, LABPC1$). The computer account is created when the computer is first joined to the domain.
| Note |
Standalone computers do not have computer accounts or authenticate to a domain.
|
At the time the computer account is created, Windows also assigns the computer a random password. The password is complex and long, and automatically changed every 30 days by default. The maximum password age can be changed using a registry edit, group policy, or local computer policy. In group policy, the maximum machine account password age can be changed at the following location:
\Computer Configuration\Windows Settings\Security Settings\Local Policies\
Security Options\Domain member: Maximum machine account age.
There should hardly ever be a reason to change the maximum password age, however. The password is so long that it should never be crackable within any of our lifetimes, and if it is compromised in clear text, the attacker has penetrated so far that changing the password is meaningless.
After the computer has successfully logged on, its password is used by a cryptographic function to establish a secure and authenticated communication channel (using RPC and SMB) between the computer and the domain controller. The computer's password is also used to establish IPsec authentication, to store other machine-specific cryptographic secrets, and for many other Windows processes requiring end-point security.
Password Storage
When a user enters their password for the first time, it is converted by a cryptographic hash algorithm to its representative obfuscated form and stored in the authentication database (SAM or Active Directory) in its hashed form. This is to complicate the job of password crackers gaining unauthorized access to the authentication database. Because the password is not stored in its plain-text form, a hacker obtaining a password hash must convert it from the hashed form to the original plain-text form. Sometimes this is a trivial process. Other times it is impossible. The longer and more complex the password is the more difficult the conversion process.
Windows has two password hash forms:
The LM password hash, developed in the early 1980s, isn't a strong cryptographic hash, and is trivial to convert to the original, plaintext form. The NT hash is a strong hash, and if the password is sufficiently long and/or complex, it is very difficult to convert. Prior to Vista, Windows stored all passwords in both hash forms, unless the password was greater than 14 characters long or if it contained unsupported characters (for example, extended ASCII). If crackers gained access to the password authentication database, they would dump the LM hashes, ignore the NT hashes, and quickly break them all.
| Note |
A good cryptographic hash has three properties:
-
Every identical input creates the same identical output every time.
-
Different inputs create different outputs.
-
If an attacker obtains the hash output, they cannot easily find the corresponding original plaintext input.
|
Starting with Windows Vista, Microsoft stores passwords in their NT password hash form only. This one change will significantly decrease the risk of password cracking from a compromised authentication database or from onthe-wire sniffing.
Authentication Protocols
Windows 2000 and later support four different authentication protocols:
-
LAN Manager
-
NTLM (version 1)
-
NTLM (version 2)
-
Kerberos
| Note |
Actually, there are two other authentication protocol versions, LAN Manager version 2, plus an unnamed, modified version of NTLM, but we will not be discussing them separately.
|
An authentication protocol is used to communicate the user's inputted password between the client and the authentication database service during a logon event. Plain-text passwords should never be sent across the network, although they often are depending on the protocol, program, or application being used. A hacker could sniff the network and pull out the plain-text password. Even password hashes should not be sent across the network. A network sniffing attacker could grab the password hash and begin cracking it, or worse, use it to authenticate directly to the network service without cracking. This is possible because of how challenge-response protocols work.
Instead, Windows uses a challenge-response authentication protocol to communicate possession of the password between the client and the server. In all four authentication protocols, the client requests to log on to the authentication database service. The client sends its logon name along with the host, workgroup, or domain requested, and other identifying or requested information. The authentication database service creates a random challenge value in the form of hexadecimal characters. The client receives the challenge characters and, using the hashed form of the inputted password mathematically manipulates the challenge using the chosen authentication protocol mathematical algorithm, to create the response.
The response is sent to the server. The server performs the same calculations on the challenge that it sent using the hashed form of the user's stored password, and if the server's calculations agree with the sent response, the user is considered successfully authenticated (because only a client with the correct password could have the correct password hash and could have correctly calculated the expected response).
This allows the client's inputted password to be communicated to the authentication database server without ever sending the password or the password hash across the network. Can the password hash still be recovered if the network is sniffed? Sure. If the attacker sniffs both the challenge and the response, the authentication protocol algorithm calculations are well documented and the password hash can be re-constructed from the captured challenge-response data. Still, it complicates network password sniffing, and if the password hash is NT (versus LM) and the password isn't simple, it doesn't' matter anyway because the password hash will be non-trivial to convert.
As stated previously, Windows 2000 and later support all four authentication protocols. Windows NT and Windows 9x computers, fully patched, support three authentication protocols excepting Kerberos. Kerberos and NTLMv2 authentication protocols are considered strong, while LM and NTLMv1 are considered weak and crackable.
By default, Windows 2000 and later domain computers will use Kerberos authentication to connect Windows 2000 and later domain resources. Otherwise (for example, local logons, legacy domains, and so on), they will send responses with both LM and NTLM. Windows Server 2003 will send only NTLM, and starting with Windows Vista, only the NTLMv2 protocol is sent for non-domain authentication. All Windows NT-based operating systems since Windows 2000 with the Security Rollup Pack 1 will accept all four (six if you count the other two undocumented) authentication protocols inbound by default. Preventing the older, insecure, protocols from being sent, as is done by default in Windows Vista prevents many password sniffing attacks and further strengthens Windows.
SAM Versus Active Directory
It's important that a Windows security administrator know where Windows logon passwords are stored. Security principal account names, their password hashes, and other related information can be stored in the local Security Accounts Manager (SAM) database or in the Active Directory database (Ntds.dit) on domain controllers. Every NT and later computer has a SAM database for local accounts. SAM databases are even used for domain authentication in NT 4.0 domains. However, only Windows 2000 and later domain controllers have Active Directory databases for domain accounts and passwords (among other things).
And on Windows 2000 and later domain controllers, the local SAM contains only two accounts: a disabled Guest account and the local Administrator account (also known as the Directory Services Restore mode Administrator). The local Administrator account can only be used only when the domain controller is rebooted in Safe mode, Directory Services Restore mode, or in the Recovery Console.
Why is this important? Because many password cracking tools crack only SAM databases and not Active Directory databases. There are about two dozen different, popular, Windows password cracking tools, with names like Pwdump, Lophtcrack, SAMJuicer, and so one. Most of these can only extract password hashes from SAM authentication databases-and most of those do not work against Windows Vista.
Cache Credentials
When a user successfully logs on to a domain from a local member computer, the user's logon credentials are stored and cached on the local computer. By default, Windows will locally cache the last ten user credentials that logged to a domain from a given computer, although that value can be modified to be anything between 0 (no cached credentials) and 50.
If the computer is unable to connect to a valid domain controller during a future logon attempt (for example, roaming laptop), Windows will use the cached domain credentials from a previous successful logon instead. This allows users to have the same user profile and desktop settings as they get when they successfully authenticate to a domain controller. Without this feature (and it can be disabled), a laptop user who disconnected from their domain would have to log on with a second local logon account name, and would receive a different user profile. Keeping both the domain and local user profile would be problematic for most users.
By default users using a cached credential will not be notified that the domain authentication event was unsuccessful. Instead, they will be allowed to logon like they normally do, except that it takes a little longer and they will notice that network resources are not available.
| Note |
There is a common misunderstanding that Windows will only allow a single user to log on ten times if their domain controller cannot be contacted. In reality, the logic is that the cached credential feature will let the last ten different users that logged onto the domain previously from the same computer to log on an unlimited number of times.
|
Windows stores a hash of the cached logon password as an encrypted MD4 hash that has been salted (i.e. a value is added to the secret before salting to make cracking more difficult) with the user's name and computed twice. Prior to Windows Vista, if a malicious attacker had local Administrator access and the appropriate hacker tool (for example, Cachedump.exe or Cain & Able) they could retrieve the stored cached password hash and attempt to convert it to the plain-text original. Windows Vista has invalidated both attack tools and further strengthened the storage of the cached password hash by encapsulating the salted MD4 hash using the PKCS#5 encryption key derivation function. This makes it effectively impossible to crack should an attacker manage to capture the cached credentials. Security administrators wishing to force a valid domain logon every time should disable cached logons, but should realize that they will need to use local accounts if the domain cannot be contacted-for example, if there is a network card failure that needs troubleshooting.
