Windows 2003 and Security

team lib

Windows 2003 security centers around access control. Access control is dependent on user identity, which is the user's user account. To gain access to a Windows Server 2003 computer or network, you must provide a user with a user account that has a valid username and password. Anyone who knows a valid username and password combination can gain access. Therefore, both the usernames and passwords of user accounts need to be protected.

Usernames are more than just names

Protecting usernames is not always simple, but a little effort can subvert several easy attacks. First, don't create usernames that employ just the first or last name of a person. Combine two or more elements to create the name, such as first name, last name , initials , department code, or division name. You should also avoid using for logon the name that's used as a user's e-mail address. This makes guessing usernames a bit more difficult. Even if a hacker knows your naming convention, making usernames complicated can make brute force attacks more difficult. (See Chapter 15 for more information on naming conventions.)

You should also rename common accounts. These include the Administrator, Guest, and IUSR_ < servername > (created by Internet Information Services, or IIS) accounts. Rename these to something descriptive but not easily guessed.

Then, create new dummy accounts with the original name that have absolutely no access, which provides a decoy for hackers, effectively wasting their time and giving you more opportunity to discover who they are.

In your security policy, you should include a restriction to prevent users from employing their network logon username as a logon name anywhere else. In other words, a user's network logon name should not be used as a logon name for Web sites, File Transfer Protocol (FTP) sites, or other external systems. If users don't use the same logon names everywhere, they'll be less tempted to use the same passwords everywhere as well.

Even with these precautions , usernames are often discoverable. The important issue here is to make obtaining any data item needed to log on to your network as difficult to get as possible. After a username is known, the responsibility of protecting your network rests on the strength of the account's password.

Passwords and security

Passwords are the primary method by which unauthorized access to a system is prevented. The stronger the password, the more likely security will remain intact. As part of your security policy, you need to require that strong passwords be used by each and every user. (See the end of this section for guidelines that lead to strong passwords.) A single account compromised can result in the entire system being accessed.

Strong passwords can be enforced using the built-in controls of Windows 2003. By employing all system-level controls that force strong passwords, little additional effort is required to ensure that users comply with the security policy.

Account policies define the restrictions, requirements, and parameters of the Password, Account Lockout, and Kerberos policies. To access the Accounts Policies, follow these steps:

  1. Choose Start Administrative Tools Active Directory Users and Computers.

  2. Select the name of your domain.

  3. Choose Action Properties.

    The domain's Properties dialog box appears.

  4. Click the Group Policy tab.

  5. Select the Default Domain Policy and then click Edit.

    The Group Policy Object Editor appears.

  6. Under the Computer Configuration node, expand the Windows Settings item.

  7. Under the Windows Settings node, expand the Security Settings item.

  8. Under the Security Settings node, expand the Account Policies item.

    Now you can see the Password, Account Lockout, and Kerberos policies in the right pane of the Local Security Settings window.

The Password Policy

After you've found the Account Policies option, you can access the Password Policy by choosing Account Policies Password Policy. The six options shown in Figure 18-1 allow you to control the requirements for user passwords. The higher you raise the bar in each of the six options, the stronger the password requirements, thus making it less and less likely that a bruteforce attack will succeed against your system.

click to expand
Figure 18-1: The Group Policy editing tool, Password Policy.

In the following list, we briefly explain each option, spell out the default setting, and recommend the most appropriate settings for general use:

  • Enforce password history: The default setting is 3. We recommend a setting of 5 or greater, which means the system will remember the last 5 passwords used by a user so he or she can't reuse any of those passwords.

  • Maximum password age: The default setting is 42 days. Use this option to define when passwords expire and must be replaced . We recommend settings of 30, 45, or 60 days.

  • Minimum password age: The default setting is 0 days. Use this option to define how long a user must wait before changing his or her password. We recommend settings of 1, 3, or 5 days.

  • Minimum password length: The default setting is 0 characters. Use this option to define the smallest number of characters that must be present in a password. We recommend at least 6 characters .

  • Passwords must meet complexity requirements: The default setting is Disabled. Complexity requirements are rules such as requiring both capital and lowercase letters , requiring the use of numerals, and requiring nonalphanumeric characters. If the native password requirements are not sufficient for you, we recommend that you research the complexity requirements further by using the Windows 2003 Help and Support feature or the Windows Server 2003 Resource Kit.

  • Store password using reversible encryption for all users in the domain: The default setting is Disabled. By enabling this attribute, you can use Shiva Password Authentication Protocol (SPAP), which is a security authentication mechanism for the Point-to-Point Protocol (PPP) developed by Shiva Corporation. Leave this disabled unless SPAP is required by a client.

The Account Lockout Policy

The next policy in Account Policies is the Account Lockout Policy, which governs when user accounts are locked out because of repeated failed logon attempts (choose Accounts Policies Account Lockout Policy). Lockout prevents brute-force logon attacks (in which every likely or possible password is attempted) by turning off user accounts. The options are as follows :

  • Account lockout threshold: The default setting is 0 invalid logon attempts. Use this option to define how many failed logon attempts result in lockout. We recommend a setting of 3 to 5 invalid logon attempts.

  • Account lockout duration: The default setting is Not defined. Use this option to define how long to lock out an account. A setting of Forever requires an administrator to un-lockout an account. We recommend a setting of 30 minutes or more.

  • Reset account lockout counter after: The default setting is Not defined. Use this option to define the time period after which the count of failed logons for a single account is reset. We recommend a setting of 15 minutes.

The Kerberos Policy

The last policy in Account Policies is the Kerberos Policy, which governs the activity of secured communication sessions (choose Account Policies Kerberos Policy). Kerberos is an advanced network authentication protocol. Using Kerberos, clients can authenticate once at the beginning of a communications session and then perform multiple tasks during that session without having to authenticate again. In other words, Kerberos is used to prove the identity of a client and a server to each other. After this identity verification occurs, communications can commence without requiring this process again (or at least not until the communications link is broken).

The options for this policy are

  • Enforce User Logon Restrictions: Enabled

  • Maximum lifetime for user ticket renewal: 7 days

  • Maximum lifetime for service ticket: 600 minutes

  • Maximum tolerance for computer clock synchronization: 5 minutes

  • Maximum lifetime for user ticket: 10 hours

For more information on Kerberos in Windows 2003, please see the Microsoft Windows 2003 and Security Web site (http://www.microsoft.com/net/technical/security.asp) and the Microsoft Security Web site (http://www.microsoft.com/security/).

A few things we know about passwords

Whether or not you enable software controls to restrict passwords, we recommend that you include the following elements in your organization's security policy regarding passwords:

  • Apply a minimum of six characters.

  • Prevent the e-mail address, account name, or real name from being part of the password.

  • Don't use common words, slang, terms from the dictionary, or other real words.

  • Don't write passwords down, except to place them in a vault or safety deposit box.

  • Don't use words, names, or phrases that can be associated with you, such as family, friends , hobbies, pets, interests, books, movies, car, or workspace.

  • If real words are used, split them with capitalization, numbers , or nonalphanumeric characters, for example, Go7Ril-la.

  • Use numbers or nonalphanumeric characters to replace letters, for example, 13TT3r.

  • Use at least three out of four types of characters: uppercase, lowercase, numerals, nonalphanumeric (symbols, punctuation).

  • Create acronyms to use as passwords from sentences, for example, Fifty-five dollars will pay a parking ticket = 55DwPaPt.

Through a combination of Windows 2003-enforced password restrictions and company security policy rules, you can improve the security of your system through the use of strong passwords.

team lib


Windows Server 2003 for Dummies
Windows Server 2003 for Dummies
ISBN: 0764516337
EAN: 2147483647
Year: 2003
Pages: 195

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net