Home > Articles > Operating Systems, Server > Microsoft Servers

This chapter is from the book

User Authentication

Almost all Terminal Server implementations require that the users perform some form of authentication in order to verify that they are who they say they are. Exceptions to this rule would include kiosk-type implementations where anonymous users access a general-purpose Terminal Server session in order to utilize a specific application. Most corporate Windows environments utilize the familiar Windows logon dialog box (see Figure 16.8) to enforce use of a user ID/password combination for user authentication. While this is the most common form of authentication, it unfortunately is also typically the weakest and most vulnerable of the security layers.

Figure 16.8Figure 16.8 The Windows Server 2003 logon window.

The reason for this weakness is not simply technical but also educational. In most organizations, the user community lacks understanding regarding the importance of adequate password "strength" and the potential consequences of a compromised user account. Password-cracking tools are readily available and can easily be used to discover weak passwords in an organization.


The term strength is often used to describe the relative complexity of a password and its resistance to cracking through either manual or automated means. Some common weak passwords include the following:

  • A blank password or no password at all.

  • Some variant of the word password.

  • A password based on the user's name, their spouse's name, or some other common dictionary word such as bird, tree, snow, monkey, dog, and so on.

  • A password based on a user's phone number, home address number, birthday, an so on.

Password-cracking tools attempt to exploit use of weak passwords and typically uÏtilize a combination of three cracking strategies to achieve their goal:

  • Dictionary attacks—Common words found in the dictionary are used to try to quickly match user passwords.

  • Targeted-word attacks—A customized dictionary of specific words is used to try to determine the user password. Custom dictionaries are usually created based on information gathered either through social engineering or other means of personal information acquisition and typically target a specific user or group of users.

  • Brute-force attacks—Every possible combination of characters is used to try to discern the password. In many cases the dictionary and brute-force attacks are integrated to try to find quick hits. With sufficient time, a brute-force attack will determine any password. Of course, the complexity and length of a password determine whether such an attack can discover a password in a realistically finite amount of time.

It is not difficult to see that these strategies would easily pick off passwords such as disney, porsche, or jennifer27, all of which are passwords I've encountered within large production Terminal Server environments.

A number of different password-cracking tools are readily available for most operating systems. A small sample of these include

  • LC5—The latest version of the famous L0phtCrack password auditing and recovery tool. Different variants of this product are available to be purchased, with the high-end product offering a number of different password-cracking techniques such as brute-force, dictionary attacks and pre-computed password tables (also known as rainbow tables). Trial versions used to be available for the product, but at the time of this writing, the latest version did not offer a trial version. The Website is http://www.atstake.com/products/lc/

  • Cain & Abel—A robust and powerful password recovery tool, Cain boasts an astounding array of features, including a number of different network packet filtering options. Best (or worst) of all, this tool is completely freeware. The product can be found at http://www.oxid.it/projects.html.

  • Sarca Rainbow Tables—An online Web site that allows you to paste LanManager and NT password hashes onto the site and submit them for cracking using their generated rainbow tables. The site only processes hashes once per day but can crack a large number of passwords. Limitations on the actual processing are discussed on the site. http://sarcaprj.wayreth.eu.org

Not only are such tools a threat on their own, but when used in combination can very easily crack even relatively complex passwords. Of course certain conditions must be met, namely the potential cracker must be able to access the encrypted passwords. In most cases administrative privileges are required to access this information, but certain exploits may make such information available without directly acquiring these rights. Just another reason for keeping up-to-date with the available security patches for your environment.

My reason for listing these tools here is purely to demonstrate how readily up-to-date password-cracking and acquisition tools are available. Listing them here does not imply that I endorse the use of these tools for anything other than testing the strength of the passwords in an environment. I recommend caution when looking to use any password-auditing tool, particularly in production.

Please understand the risks involved in such endeavors. Use common sense when downloading and testing any software that may be coming from a suspect source.

While it is obvious that a "strong" password will be much more difficult to crack than a "weak" one, the added complexity can be a formidable obstacle during early stages of implementation, with the primary issue being simply that it is more difficult for the end user to remember a new, stronger password. In nearly every situation where I have been party to introduction of complex password requirements, the end user community in general has commented that the new passwords are "far too confusing," and "not necessary" for their organization or department. Without the proper education, users are unclear as to why they must use a complex password and as such become easily frustrated if the simple tasking of logging on is delayed enough to impact their ability to work. Failure to successfully introduce and enforce strong-password requirements in most cases is a result of the system administrator's inability to adequately manage the initial flood of demands from users requesting password resets or unlocking of a locked-out account in a timely fashion.


Microsoft has tried to stress to administrators the idea of teaching users the concept of a "passphrase" instead of simply a password. While many users can struggle with trying to come up with and remember a seven-character password, a common phrase such as "I really love to drink coffee" can be easier to remember, easier to type, and stronger than a typical seven-character password. In an environment that is enforcing complex passwords, one way to ease password creation is to develop a passphrase that can then be used to "build" the password.

For example, a common technique I've used is to create a passphrase such as "Todd loves to spend money on his sports car." I then delete all but the first letter of each word and substitute the word to with 2 and money with $. The result is the password Tl2s$ohsc, which is suitably complex and also very easy to remember. I talk more about enforcing strong passwords in the next section of this chapter.

Account Password Policies

Unfortunately, education alone rarely ensures that all users in your organization use only a strong password. Most users, given the opportunity, try to use as simple a password as possible and recycle this password (or minor variations) over and over, if periodic password changes are required. As a general rule, an administrator should never leave it solely up to the end user to ensure that a sufficiently strong password is being used.

As a complement to user education, an administrator should leverage the security features available in Windows 2000/2003 to help enforce strong user password requirements. Both Windows versions support the same six password policies shown in Figure 16.9. A subset of these policies is enabled by default in a Windows 2003 domain; unfortunately the same cannot be said for a Windows 2000 domain, where none of these policies is enabled by default.

To modify the default password requirements in a Windows domain, these settings must be defined within the Default Domain Policy group policy object (GPO), located at the root of the domain. For example, in my noisyriversoftware.com domain, this GPO is found under the Group Policy tab for the noisyriversoftware.com object. If you wish to define these password settings for local accounts on a member server or PC, a GPO containing these settings must be created and assigned to an OU that contains the computers you want to update.


Many organizations make the mistake of assuming that only those accounts with administrative privileges require strong passwords and that "regular" user accounts are not really as much of a concern. This is a dangerous misconception, particularly in an environment where regular patch management is not being performed. Frequently exploits are discovered that make it possible for a regular user to elevate their privileges beyond what they have been assigned and to gain full administrative control. Because of this, password security really must be enforced for all users in your environment and not only for those users with administrative privileges.

Figure 16.9Figure 16.9 Windows 2000/2003 account password policies.

The six policies shown in Figure 16.9 provide the following functionality:

  • Enforce password history—To counteract the tendency of users to reuse the same password (or small set of passwords) over and over, this policy ensures that a specific number of unique passwords are used before a user's oldest password can be reused. By default this option is set to the maximum of 24 passwords remembered in a Windows 2003 domain.

  • A possible side effect of enforcing a lengthy password history is that users may start maintaining a paper record of their password to help them remember what they are currently using. The two most effective ways to counteract this are through the proper education of secure computing practices and the use of a suitably long maximum password age (described next) to allow the user time to learn the password before the system once again requires them to change it. My preference is to use the maximum value of 24 in all production Windows domains whenever possible.

  • Maximum password age—The longer a user is allowed to retain the same password, the greater the chances that the account may be successfully cracked or accessed by someone who may already have the password to the account. Periodically forcing a user to change their password helps minimize these risks. A Windows 2003 domain has a maximum password age of 42 days, which most administrators find to be an optimal medium between frequent password change requirements and adequate password aging.

  • Similar to enforcing a large password history, requiring users to change their passwords too often will likely result in at least some of the users keeping a paper record of their current password, often in an easily accessible location (taped to the monitor, under the keyboard, and so on). I highly recommend not setting the maximum password aging to zero (0) but instead using the default of 42 days.

  • Minimum password age—Complimenting the maximum password age policy is the minimum password age policy. This policy defines the minimum number of days a user must use the same password before it can be changed. The main reason for this policy is to ensure that users do not attempt to quickly change their password multiple times in order to reuse a desired password, effectively circumventing the "Enforce password history" policy.

  • Windows 2003 defaults to a minimum password age of one (1) day, meaning that a user can change their password only once per day. This policy does not prevent an administrator from resetting a user's password.

  • Minimum password length—An adequate password length is critical to ensuring that user passwords remain secure by minimizing the effectiveness of brute-force attacks. Each increase in the minimum password length by one character exponentially increases the number of possible password permutations. Using only the standard characters on the keyboard, users have 94 possible characters to choose from when selecting their password. These 94 characters are comprised of 52 alphabetical characters (uppercase and lowercase), 32 additional characters (#, $, *, @, etc.), and 10 numeric characters (0, 1, 2, 3, etc.). When the minimum password length is 7, the user can choose from 947 (approximately 64,000,000,000,000) possible different passwords.

  • Of course, as the password length increases, so does the risk that a user will be unable to remember the password they are using. Windows 2003 defaults to a minimum length of seven characters, and I recommend that passwords use at least this many characters.

  • Password must meet complexity requirements—Even with all these password requirements in place, education alone will not ensure that the end user consistently selects a strong password. Without some means of ensuring that a minimum level of strength is being used, the users are likely to pick the simplest password possible that complies with the policies in place.

  • The "Password must meet complexity requirements" policy lets you enable your Windows environment to perform a complexity validation check whenever a user's password is changed. Here are the complexity requirements

Password must have a minimum length of six characters.

This requirement takes priority over the "Minimum password length" policy if the minimum length has been set to less than six characters.

The password must contain characters from at least three of the following categories:

  • Uppercase characters "A" through "Z."

  • Lowercase characters "a" through "z."

  • Numeric characters 0 through 9.

  • Non-alphanumeric symbols such as !, @, #, %, and so on.

The password cannot contain substrings of three or greater characters in length found in the user's full account name. When this requirement is validated, the user's full name is broken up into substrings using commas, periods, dashes, hyphens, underscores, number signs, and spaces as string delimiters. The password is then searched for substrings matching these tokens. If any matches are found, the password is rejected. Any substrings of three or fewer characters are ignored. For example, if a user has the name Steven Li Chan, it is broken into three substrings: "Steven", "Li", and "Chan". The name "Li" is dropped because it is less than three characters, while the other two tokens are used to search the password. If either "Steven" or "Chan" appears in the password, it is rejected. The searches are case insensitive, so "CHaN", "chan", and "ChaN" are all considered to be the same.

When a user's password is changed and it fails validation, a message similar to the one in Figure 16.10 appears. The Windows 2000 message differs slightly, providing a more verbose description of the password requirements. Invariably, when this policy is first implemented, users have a difficult time interpreting the password requirements. I've found that a separate description of the password requirements (including some password examples) made available to the user, either via an e-mail message or as a physical printout, can greatly ease transition pains associated with enforcement of complex passwords.

Figure 16.10Figure 16.10 A Windows Server 2003 complex password requirements message.


Password validation requirements are provided as part of the passfilt.dll system file. When a password change request is made, the Local Security Authority (LSA) module of the Windows subsystem calls the password filters provided in this DLL to validate the password requirements. While the password requirements supplied with the default passfilt.dll file cannot be modified, a custom passfilt.dll file could be created containing customized password requirements for your organization. Details of such an undertaking are beyond the scope of this book, but if you are interested, you can find more information on the Microsoft Developers Network (MSDN) Web site at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/strong_password_enforcement_and_passfilt_dll.asp

  • Store passwords using reversible encryption—In most situations, this policy should never be enabled because it forces Windows to store passwords in such a way that they can be decrypted. This is inherently much weaker than the standard method of one-way encryption and provides an attacker with an additional means of compromising one or more user accounts.

With proper use of these six security policies you can minimize the vulnerabilities traditionally found with ID/password user authentication.

Account Lockout Policies

In addition to enforcing use of strong passwords, another mechanism for increasing security of Windows user authentication is use of user account lockout policies. Essentially, these policies provide a means of temporarily disabling a user's account if a predefined number of unsuccessful user ID/password authentication attempts are performed within a given period of time. Figure 16.11 shows the three account lockout policies found in both Windows 2000 and Windows 2003. By default none of these options are enabled in either operating system.

Figure 16.11Figure 16.11 Windows Server 2003 account lockout policies.

The three policies shown in Figure 16.11 provide the following functionality:

  • Account lockout duration—This policy determines the amount of time a user's account remains disabled until it is automatically re-enabled by the system. I typically recommend that the duration be set to zero (0) in order to minimize the number of brute-force or dictionary-based attempts that can be performed against a user account before an administrator's intervention is required. When set to zero, an account remains locked until manually unlocked by an administrator.

  • The one thing to consider when setting the lockout duration to zero is that a user cannot log on until an administrator manually re-enables the account. To minimize the chances of a user legitimately locking themselves out, settings for the other two account lockout policies must be set accordingly, as discussed in the following points.

  • Account lockout threshold—The lockout threshold represents the number of incorrect password attempts allowed before a user's account is disabled. One factor influencing this value is the lockout duration you configured for your environment. If the duration is set to zero (0), the lockout threshold can typically be assigned a value of 10 to 15. In most situations a user is not likely to repeatedly try their password this many times within the account lockout reset interval (see the following point).

  • Reset account lockout counter after—This setting dictates the amount of time that must pass before the lockout counter is automatically reset to zero. A value of 30 minutes is usually appropriate for most environments.

When first implementing account lockout policies in your organization, it is not unusual to see a high number of account lockouts occur, particularly when first implementing strong password requirements. It will likely take a few days before the issues balance out to an acceptable level. At this time you may need to make minor adjustments to your configuration to reach a mutually agreeable configuration for both users and administrators.


An unfortunate downside that exists when lockout policies have been implemented is that a malicious user could exploit this configuration to purposely lockout user accounts, effectively performing a denial of service (DOS) attack on the environment. This is one of the reasons why the administrator's account cannot by default be locked out. While there is no sure-fire way to prevent this, limiting external access to the environment as much as possible will at least help to contain such a threat to within the confines of the internal network.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020