Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Logon Process

To access most resources on Windows computers based on NT technologies, a user must know a valid account name in the account database of the computer or domain and the password for that account. Then she must use this information to log on. Users are not the only security principals (objects that can be granted rights and permissions on Windows systems). In a Windows domain, those computers (Windows NT 4.0, Windows 2000, Windows XP Professional, and Windows Server 2003) that can become domain members are also considered security principals and, like users, must be provided a domain computer account.

Both users and computers use the logon process to authenticate. The details of the logon process may vary based on operating systems, account type, logon type, and credentials, but the basic steps are similar. The process includes three steps:

The security principal (user or computer) must present a user ID or other identity symbol such as a smart card.

When requested, the security principal must present credentials. Credentials may be a password, biometric, token, or PIN.

The combination of identity symbol and credentials are validated or rejected. The validation process consists of identifying the account as legitimate, satisfying account restrictions (logon hours, for example), and evaluating the proof of identity (password or other factor) provided. If the logon is not local, (based on an account database on the same computer), a network authentication protocol is used.

Password Storage

Passwords are not stored in the Windows password database in clear text. Instead, a hash of each password is stored. A hash is the result of taking a variable-length binary input and processing it to produce a fixed-length binary output. When a good hashing algorithm is used, it is statistically infeasible that two different inputs will produce the same output. This also means that the same input will always produce the same output. A cryptographic hash uses a secret key to protect the results of the process. Cryptographic hashing is a one-way function (OWF); that is, the process is irreversible. Unlike the results of secret key encryption, the cryptographic hash cannot be decrypted.

The hash used in Windows is a cryptographic hash, and thus the process is irreversible. This is why a comparison process is used during authentication. A sound hash algorithm will never reduce different bits of data to the same result, so if the result of hashing the entered password matches the stored password hash, then the password has been validated, and the user has proved his or her identity to the system.

NOTE: Reality Check

In reality, no existing hashing algorithm is perfectly sound. That is, mathematically there is the possibility that two different passwords might hash to the same result or produce a collision. The question to ask here is not whether we should throw out hashing algorithms as security tools for password storage, but rather how likely the collision is and how easy it would be for someone to use this possibility to crack passwords. At this point, the possibility of collision is considered slight enough and the difficulty of exploiting this flaw is high enough to justify continuing to use current hashing algorithms while seeking better ones and alternative mechanisms. (Current password cracking tools do not crack passwords by using this flaw.)

Password hashes for local accounts are stored in the local account database, the security accounts manager (SAM), on the local computer, or, when accounts are domain accounts, in the domain password database in the Active Directory. During local logon, when a user presents a password, the hash cannot be decrypted, so the same cryptographic hashing process is used on the entered password, and the results are compared to the stored hash. If both hashes match, then the passwords match, and the user is authenticated.

Logon Types

The exact process used during authentication is dependent on the logon type. Logon types are as follows:

Interactive
In most cases, the user provides credentials at a console. Exceptions are some types of remote logon such as web server access that require interactive logon permissions but for which the user does not have to log on from the console. The user's credentials are checked against the user account database either in the SAM if the account is local or in the Active Directory if it is the domain account. If the account is a domain account, Kerberos is used by default. In an Active Directory forest, a user's domain account can be used for approved access to resources in any domain in the forest. Cross-forest trusts can extend this access to other external domains. The ability to use a single account for such wide-reaching access is known as single sign-on.

Network
Provides proof of the user's identity to a network service or resource that the user is attempting to access. Many types of network authentication are available, such as Kerberos V5, Secure Socket Layer/Transport Layer Security (SSL/TLS), and, for compatibility with Windows NT 4, NTLM. Network authentication occurs when a domain account (an account stored in a domain database) is used or when a remote resource is accessed.

Anonymous
No user account or credentials are required.

NOTE: Variations on Logon Types

Microsoft extends these definitions with additional types of logon, including batch (executing on behalf of a user), service (a service starts), unlock (a locked computer was unlocked), network clear text (password passed in clear text across the network), new credentials (new credentials are used for other network connections), remote interactive (Terminal services or Remote desktop), and cached interactive (locally cached credentials are used and no domain controller was contacted.) However, these are only slight variations of the following explanations.

Interactive Logon Process Details

When the logon process is interactive (a user is sitting at a Windows computer), the following steps are used:

The user provides an attention signal, such as the CTRL+ALT+DEL key combination, the insertion of a smart card, or the presentation of a biometric.

The Winlogon service calls the Graphical Identification and Authentication (GINA) dynamic link library (dll), and the logon screen is presented. (When the logon process involves something other than passwords, the GINA may be altered or replaced and a different screen may appear.)

The user provides credentials in the form of a user ID and password or, in the case of a smart card, a PIN. After entering the data, the user may need to click an OK button.

The Local Security Authority (LSA) processes the credentials.

If a user ID and password are used, the LSA user function converts the credentials into the same form in which they are stored in the account database (either the local SAM or domain controller resident Active Directory). In an unmodified Windows Server 2003 server, two storage forms are prepared and storedan LM hash and an NTLM hash. If a smart card is used, the LSA uses the entered PIN (if it is valid) to obtain the private key of the user's smart card certificate from the smart card.

Account restrictions are checked. Account restrictions are things such as Account is disabled or Smart card is required for interactive logon.

User logon rights, such as the right to log on locally, are checked and the credentials are validated.

If the logon is local, the LSA compares the result of step 5 with the hashed password data stored in the local SAM. If the result is a match, the user is authenticated and access is provided.

If the logon is to a domain, the authentication package MSV_0, which includes Kerberos, LM, and NTLM, is used to validate the credentials.

Smart Card Processing

Native Windows Server 2003 smart card processing is integrated into Windows Server 2003 certificate services and is available only in an Active Directory domain. Smart card authentication also uses certificates for the initial Kerberos processing. More information is provided in the "Certificates, Smart Cards, Tokens, and Biometrics" section later in this chapter and in Chapter 13, "Implementing a Secure PKI."

Domain and Network Authentication

Local interactive logon simply compares a password hash to the hash stored in the local account database, the SAM.

When a domain account is used, the process is different. A network authentication protocol, such as Kerberos, LAN Manager (LM), NT LAN Manager (NTLM), or NTLM version 2 (NTLMv2), is used. A network authentication protocol is also used when a user requests access to a network resource. For example, if a user attempts to access files on a network file server, he must first authenticate to the file server. The remote authentication process is transparent to the user when the process is able to use currently cached logon credentials (password hash or Kerberos tickets). If the ticket has expired and cannot be renewed, or if the credentials for the account on the remote system do not match those used by the logged-on user, a prompt for new credentials may appear.

Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

فارسی

کردی

العربیه

اردو

Türkçe

Русский

English

Français

کانال فیلم من

تبیان من

فایلهای من

کتابخانه من

پنل پیامکی

وبلاگ من

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی