What command below can be used to reset the default gpos to their original settings?

Account Lockout Policies

Account lockout policies are used by administrators to lock out an account when someone tries to log on unsuccessfully several times in a row. We can usually assume that a legitimate user might type his or her password incorrectly once or twice, but not numerous times. Thus, numerous failed logons can indicate that someone is trying a brute-force password attack (trying to keep guessing the password until he or she gets it right). There are three options:

Account lockout duration You can specify the time in minutes that the account can be locked out. For example, if the account locks out for two hours, the user can try again after that time. The default is no lockout. When you define the policy, the default time is 30 minutes. The setting can be from 0 to 99,999. When set to 0, the account will remain locked out until an administrator manually unlocks it.

Account lockout threshold This specifies the number of failed attempts at logon a user is allowed before the account is locked out (for example, three). After the threshold has been reached, the account will be locked out. If this value is set to 0, the account will not lock out. This setting can be from 0 to 999.

Reset account lockout counter after You can choose to have the account lockout counter reset after a number of minutes. At that time, the count will start over at one.

Applying an Account Lockout Policy

In addition to setting password policies, you can configure your network so that user accounts will be locked out after a certain number of incorrect logon attempts. This can be a soft lockout, in which the account will be re-enabled after an administrator specified period of time. Alternatively, it can be a hard lockout in which user accounts can only be re-enabled by the manual intervention of an administrator. Before implementing an account lockout policy, you need to understand the potential implications for your network.

An account lockout policy will increase the likelihood of deterring a potential attack against your network, but you also run the risk of locking out authorized users. You need to set the lockout threshold high enough so that authorized users will not be locked out of their accounts due to simple human error, such as mistyping their passwords before they’ve had their morning coffee. Three to five is a common threshold. You should also remember that if a user changes his or her password on Computer A while already logged on to Computer B, the session on Computer B will continue to attempt to log on using the old (now incorrect) password. This will eventually lock out the user account and can be a common occurrence, especially in the case of service and administrative accounts. Exercise 3.03 details the necessary steps in configuring account lockout policy settings for your domain.

Exercise 3.03

Creating an Account Lockout Policy

From the Windows Server 2003 desktop, click Start | Administrative Tools | Active Directory Users and Computers.

Right-click the domain you want to administer, and then select Properties.

Select the Default Domain Policy, and dick the Edit button.

Navigate to the account lockout policy by clicking Computer Configuration | Windows Settings | Security Settings | Account Policies | Account Lockout Policy. You’ll see the screen shown in Figure 3.7.

Using Account Lockout Policy, you can configure the following settings:

Account lockout duration This option determines the amount of time that a locked-out account will remain inaccessible. Setting this option to 0 means that the account will remain locked out until an administrator manually unlocks it. Select a lockout duration that will deter intruders without crippling your authorized users; 30 to 60 minutes is sufficient for most environments.

Account lockout threshold This option determines the number of invalid logon attempts that can occur before an account will be locked out. Setting this option to 0 means that accounts on your network will never be locked out.

Reset account lockout counter after This option defines the amount of time in minutes after a bad logon attempt that the “counter” will reset. If this value is set to 45 minutes, and user jsmith types his password incorrectly two times before logging on successfully, his running tally of failed logon attempts will reset to 0 after 45 minutes have elapsed. Be careful not to set this option too high, or your users could lock themselves out through simple typographical errors.

For each item that you want to configure, right-click the item and select Properties. To illustrate, we create an Account lockout threshold of three invalid logon attempts. In the screen shown in Figure 3.8, place a check mark next to Define this policy setting, and then enter the appropriate value.

Exam Warning

The issue of password synchronization described in the previous paragraph is not an issue for organizations that are only running Windows Server 2003 operating systems.

Security Policies

▪

Use account lockout policies only in controlled environments or where the risk of a compromised account is greater than the risk of continual DoS attacks.

Insert random delays in the authentication process to slow brute-force attacks.

Consider blocking IP addresses with multiple failed login attempts, but take into consideration the impact of blocking a proxy used by multiple clients.

Vary responses to both failed and successful password authentication.

Ask users to answer their secret questions after seeing multiple failed logins.

Provide user options to limit account login to specific IP addresses.

Use unique login URLs for different blocks of users.

Use a CAPTCHA to prevent automated attacks.

Limit an account's capabilities if an attack is suspected.

Fine-Grain Password and Account Lockout Policies

When a GPO is used to apply password and account lockout policies, these policies can be set for only the entire domain, and only one instance of each setting will be applied to for all users in the domain. In other words, you cannot set different password or account lockout policies for different types of users in a domain (such as administrators and general users) using GPOs. You can do this only using a new feature, fine-grain password and account lockout policy. A key distinction between group policy-based user and account lockout enforcement and fine-grain policies is how you apply them. Unlike group policy, however, fine-grain policies are quite complex to configure.

You can apply fine-grain policies only to users and global security groups. They are not linked to the major Active Directory container objects: sites, domains, and organizational units (OUs). It is common for organizations to organize users using these traditional Active Directory container structures, so Microsoft recommends the creation of shadow groups which map to an organization's domain and OU structure. In this way, you can add the global security groups to the appropriate fine-grain policy object in Active Directory one time, and use group membership to determine to whom it applies. It's possible that a user can be a member of more than one global security group and for these groups to be associated with different fine-grain policies. To accommodate this, Microsoft allows you to associate a precedence value to each fine-grain policy. A policy given a lower number will take precedence over one given a higher number if both apply to a user.

Notes from the Underground…

Configuring a Fine-Grain Password Policy

Two new Active Directory object classes have been added to the Active Directory schema to support fine-grain policies. Policies are configured under a Password Settings Container (PSC). The actual policy objects themselves are called Password Settings objects (PSO). Creating a PSO involves using a lower-level Active Directory editing tool than you might be familiar with. There are two ways to do it. One is with the ADSI Edit graphics utility. The other is by using ldifde to script the operation at the command line. In this chapter, we'll be using ADSI Edit:

1

Open ADSI Edit by clicking Start | Run and type in adsiedit.msc.

2

Right-click on the ADSI Edit node in the leftmost pane and click Connect to. (See Figure 3.6.)

Figure 3.6. Bringing Up the Connections Settings Dialog

3

Accept the default naming context which appears in the Name: text box or type in the fully qualified domain name (FQDN) of the domain you want to use. Click OK. (See Figure 3.7.)

Figure 3.7. The Name: Text Box

4

Expand the Default naming context node (if present), rxpand your DC=DomainName node (here, DC=syngress,DC=com), and double-click on the CN=System node.

5

Right-click on the CN=Password Settings Container node and select New | Object, as shown in Figure 3.8.

Figure 3.8. Creating the New Object in ADSI Edit

6

In the Create Object dialog box, select msDS-PasswordSettings and click Next. (See Figure 3.9.)

Figure 3.9. Selecting the msDS-PasswordSettings Option

7

In the Create Object dialog box, enter the desired name for your PSO in the Value: text box (here, psoUsers) and click Next. (See Figure 3.10.)

Figure 3.10. Entering the PSO Name

8

Configure the appropriate value for each of the password and account lockout policy settings. All are required. Refer to the information in the list after Figure 3.11 for more details on each setting.

Figure 3.11. Configuring the Fine-grain Settings

▪

msDS-PasswordSettingsPrecedence Sets the precedence value for deciding conflicts when more than one fine-grain policy applies to a user. Values greater than 0 are acceptable.

▪

msDS-PasswordReversibleEncryptionEnabled Equivalent to the Store passwords using reversible encryption group policy setting. Acceptable values are TRUE and FALSE.

▪

msDS-PasswordHistoryLength Equivalent to the Enforce password history group policy setting. Acceptable values are 0 through 1024.

▪

msDS-PasswordComplexityEnabled Equivalent to the Passwords must meet complexity requirements group policy setting. Acceptable values are TRUE and FALSE.

▪

msDS-MinimumPasswordLength Equivalent to the Minimum password length group policy setting. Acceptable values are 0 through 255.

▪

msDS-MinimumPasswordAge Equivalent to the Minimum password age group policy setting. Acceptable values are (None) and days:hours:minutes:seconds (i.e., 1:00:00:00 equals one day) through the value configured for msDS-MaximumPasswordAge.

▪

msDS-MaximumPasswordAge Equivalent to the Maximum password age group policy setting. Acceptable settings are (Never) and msDS-MinimumPasswordAge value through (Never). This value cannot be set to 0. It follows the days:hours:minutes:seconds format (i.e., 1:00:00:00 equals one day).

▪

msDS-LockoutThreshold Equivalent to the Account lockout threshold group policy setting. Acceptable settings are 0 through 65535.

▪

msDS-LockoutObservationWindow Equivalent to the Reset account lockout counter after group policy setting. Acceptable values are (None) and 00:00:00:01 through msDS-LockoutDuration value.

▪

msDS-LockoutDuration Equivalent to the Account lockout duration group policy setting. Acceptable values are (None), (Never), and msDS-LockoutObservationWindow value through (Never). This value follows the days:hours:minutes:seconds format (i.e., 1:00:00:00 equals one day).

9

After specifying the preceding values, click the More Attributes button, as shown in Figure 3.12.

Figure 3.12. The More Attributes Button

10

Although it is not required, at this point you can specify to which users or groups the fine-grain policy will apply. You can also do this in Active Directory Users and Computers (covered later). To configure this during PSO object creation:

Set Select which properties to view: to either Optional or Both.

Set Select a property to view to: to msDS-PSOAppliesTo.

Enter a distinguished name (DN) for a user or global security group in the Edit Attribute: text box and click Add. Multiple users and groups can be added and removed. When done, click OK. (See Figure 3.13.)

Figure 3.13. Associating Users and Global Security Groups

11

Click Finish in the Create Object dialog box. When done, ADSI Edit should resemble Figure 3.14.

Figure 3.14. The ADSI Utility

Applying Users and Groups to a PSO with Active Directory Users and Computers

In addition to using ADSI Edit to associate users and global security groups with a PSO, administrators can also use Active Directory Users and Computers:

1

Open Active Directory Users and Computers by clicking Start | Administrative Tools | Active Directory Users and Computers.

2

Ensure that View | Advanced Features is selected.

3

In the left pane, navigate to Your Domain Name | System | Password Settings Container.

4

In the right pane, right-click on the PSO you want to configure, and select Properties, as shown in Figure 3.15.

Figure 3.15. Opening the Properties for the PSO

5

In the Properties dialog box, select the Attribute Editor tab. In the Attributes: selection window scroll down and click on msDS-AppliesTo followed by Edit. (See Figure 3.16.)

Figure 3.16. The Attribute Editor Tab

6

There are two ways to add users and global security groups using the Multi-valued Distinguished Name with Security Principal Editor dialog (see Figure 3.17):

Click Add Windows Account to search for or type in the object name using a standard Select Users, Computers, or Groups dialog box.

Click Add DN to type in the DN for the object you want to add.

Figure 3.17. The Multi-valued Distinguished Name with Security Principal Editor Window

7

You can also remove accounts from the Multi-valued Distinguished Name With Security Principal Editor dialog by highlighting the account in the Values: selection box and clicking the Remove button. When you are done adding and deleting accounts from this PSO, click OK.

8

In the Properties window, click OK.

Configuring Account Lockout in Active Directory

Although you're configuring the password policy settings, it's a good idea to also configure the Account Lockout Policy. To do this, expand Account Lockout Policy. Double-click on Account lockout threshold. In the Account lockout threshold Properties dialog box, change number of invalid login attempts to 6. A dialog box will pop up and ask if it should also change the Account lockout duration and Reset account lockout counter after attributes as well. These should both be changed to 30 min to comply with PCI requirements, which is what the default is in this new dialog. Click OK. It should now look like Fig. 5.2.

Security Templates and Tools

There are numerous settings, or customizable security policies, that you can apply through security templates, including the following:

Account Policies Include password policies, Kerberos policies, and account lockout policies.

Local Policies Include user rights, audit policies, and other security options.

Event Log Include configuration options for the Application, System, and Security event logs that can be viewed through Event Viewer.

Restricted Groups Used to specify group memberships.

System Services Used to configure permissions and startup options for services.

Registry Used to specify permissions and for auditing Registry objects.

File System Used to specify permissions and for auditing files and folders.

You can create and edit security templates using the Security Templates snap-in for the Microsoft Management Console (MMC), as explained in the “Creating Custom Security Templates” section later in this chapter. This tool allows you to manage your own templates, but you can also use predefined templates that come with Windows Server 2003. The next sections describe the predefined templates and the tools for working with security settings.

Account security policies

User account security policies help ensure that user accounts are protected and properly secured. Using account security policies, you can set the following account policies for AD accounts:

Password Policy

Account Lockout Policy

Kerberos Policy

The password policy allows you to configure requirements for user passwords. The password policy options are defined in Table 4.2.

Table 4.2. Active Directory Domain Password Policy

Notes from the field

In addition to the password policy, you can set an account lockout policy. The account lockout policy “locks” the user's account after a defined number of failed password attempts. The account lockout prevents the user from logging onto the network for a period of time even if the correct password is entered. You should set an account lockout policy to help thwart off those who may attempt to compromise user accounts by brute force methods of guessing username and password combinations. The account lockout policy contains the following settings:

Account lockout duration—This is the amount of time the account will remain locked out. This is commonly set to 20 or 30 min. An administrator can manually unlock the account at any time after it has been locked.

Account lockout threshold—This is the number of invalid log-on attempts allowed before the account is locked out. After the defined threshold is reached, the account then becomes locked until the account lockout duration passes or an administrator manually unlocks the account.

Reset account lockout counter after—This setting defines the number of minutes that must pass before the lockout counter will set itself to zero after an invalid log-on attempt has been detected.

The third account policy is the Kerberos Policy. This policy allows you to define Kerberos authentication settings. Kerberos authentication is discussed in Chapter 11. The Kerberos policy has the following definable settings:

Enforce user logon restrictions—By enabling this setting, the Kerberos Key Distribution Center (KDC) will validate each ticket request against the user account rights policy.

Maximum lifetime for a service ticket—This setting defines how long a service ticket is valid. After the ticket expires, the user account will be rejected by the resource and will have to request a new ticket from the KDC.

Maximum lifetime for a user ticket—This setting defines the maximum age in minutes that the user ticket or ticket granting ticket (TGT) is valid.

Maximum lifetime for user ticket renewal—This setting defines the number of days that a TGT can be renewed for continued use.

Maximum tolerance for computer clock synchronization—Kerberos is time-sensitive protocol. This is a security feature to ensure that expired tickets cannot be used because of computer clocks being set incorrectly. This setting allows you to set the maximum amount of time difference Kerberos will allow between the domain and computers joined to the domain.

The account policies are set using the Group Policy Management console located in Server Manager. To manage the account policies, you need to edit the default domain group policy. Perform the following tasks to modify account policies:

Open Server Manager.

Expand the nodes Features | Group Policy Management | Forest: <your forest name> | Domains | <your domain name>.

Right-click the Default Domain Policy and choose the Edit option.

Expand the nodes Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies.

Select the policy you want to modify. After making changes, close the Group Policy Management Editor. Changes will be automatically saved.

Password Policies in SQL Server 2005

Password policies are a new feature in SQL Server 2005. So what are password policies? They are a series of rules enforced to ensure passwords in SQL server follow standards set forth in the operating system via group policy.

Password policies can be turned off and on in SQL server. There may be reasons for not using password policies overall, or just on specific accounts.

Using the Group Policies Console

The easiest way to use the group policy console is to start the management console by typing “MMC” in the run box in Microsoft Windows. To access the run box, click the Start menu, and select the run box. The Microsoft management console has other functions besides controlling group policy.

Once the MMC is started, you need to click Add/Remove Snap-in. The “Add/Remove” snap-in option is available on the file menu (see Figure 6.1).

Figure 6.1. Adding the Snap-in (Part 1)

Click the Add/Remove Snap-in menu selection, and a dialog that allows selection of snap-ins to be added will be presented. It is recommended that you select only the add-in for group policy; otherwise, the menu can get very cluttered very quickly.

Scroll down and select the Local Group Policy Object, and click the Add button (see Figure 6.2). Note that when using Microsoft Windows 2003 or Microsoft Windows XP, the dialog boxes may look slightly different.

Figure 6.2. Adding the Snap-in (Part 2)

When you add the snap-in after selecting it and click OK, the selection of which computer you wish to manage dialog will be presented (see Figure 6.3). Note that it’s not necessary to be logged in to the computer to be managed, but the account used needs administrative rights on the computer to be managed.

Figure 6.3. Selecting the Computer

After you select the computer (in most cases it will be the local computer), the initial Group Policy Management console snap-in screen will be presented (see Figure 6.4).

Figure 6.4. The MMC Initial Screen

As one can see in group policy, there are also a number of other items to be controlled. It is strongly suggested to refrain from changing anything, unless the impact is known, as there is no “undo” for the settings in group policy. Once a change is made, if the previous value is forgotten, there is no way to go back and see what it was.

In order to use the group policy snap-in to control the password policies, expand the tree under “console root” on the left-hand pane.

Expand each of the nodes under “Windows Settings” until Account Policies is shown.

Some Independent Advice

Group policy is complex in the way it’s applied. Group policy is applied at different points (at the domain or group level in Active Directory). Active Directory provides an option that will not allow group policy settings to be overridden. In the event an option is configured to not be overridden at a higher level, even if it has been set at the local level, the setting won’t take effect if it’s set via Active Directory.

This is why it is important to involve the appropriate groups in your organization when working with group policy.

Password Policies

The following password policies can be enforced in SQL Server 2005:

■

Password history

■

Minimum password age

■

Maximum password age

■

Minimum password length

■

Complexity requirements

Figure 6.5 depicts the password settings in the management console for group policy.

Figure 6.5. Group Policy for Passwords

Let’s discuss each of these options in more detail.

The “Enforce password history” option is used to prevent users from reusing old passwords. This makes the system more secure; a user needs to use a new password (one that has never been used before) each time they change the password. Valid values for this are between 0 and 24. The default is 24 on domain controllers and 0 on stand-alone servers. It would be bad practice to install SQL server on a domain controller, so I would surmise that it will be 0 on your server. If this option is to be used, it is a good idea to also use the “Minimum password age” option as well.

The “Minimum password age” option is used to set the period of time in days that the password must be used before the user can change it. On the surface, you’d wonder why you’d want to use this setting, but it has an important use. It also prevents users from changing the password in order to defeat the “Enforce password history” option, by going through passwords until they get back to an old favorite. This also helps to discourage users from changing their passwords so frequently that they forget them. The default is 0, which allows the user to change the password at any time. Note that the “Minimum password age” must be less than the “Maximum password age.”

The “Maximum password age” is used to set the period of time in days that a password may be used before requiring the user to change it. This can be set from 0 (never expire) to 999. Note that the “Minimum password age” must be less than the “Maximum password age.”

The “Minimum password length” option is used to set the minimum password length for a password. This can be set from 0 to 14. When the “Minimum Password Length” is set to 0, it allows for any length password.

The “Password must meet complexity requirements” option is used to set complexity requirements, causing the password to be more secure and less apt to guessing.

The attributes of the password must be as follows when the complexity requirements option is enabled:

■

The password must not contain the user’s account name or parts of the user’s full name that exceed two consecutive characters.

■

The password must be at least six characters in length.

■

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

English uppercase characters (A through Z)

English lowercase characters (a through z)

Base 10 digits (0 through 9)

Nonalphabetic characters (for example, !,$,#, %)

Complexity requirements are enforced when passwords are changed or created.

Some Independent Advice

It’s usually a good idea to enable the “Password Must Meet Complexity Requirements” option; however, it’s also a good idea to communicate this to your users prior to enabling this, as it can lead to user confusion when they attempt to change their passwords and may result in an increase in support calls to your helpdesk.

Using the Local group policy console to administer settings is easy. Double-click on the setting to be changed and a dialog box will be presented where changes will be made. The console checks the values to be sure they are within the proper range. Double-click on the option, and a dialog box similar to that in Figure 6.6 will be presented.

Figure 6.6. The UI for Administering Settings

Note

If more information is needed about what a setting does, the Group Policy Snap-in provides an explanation for each of the settings. When an item is double-clicked, a tab to see a detailed explanation is available. Clicking the Explain tab will present the information (see Figure 6.7).

Figure 6.7. A Group Policy Setting Explanation

The explanations are very clear and concise, and they usually show the default values as well as ranges for the settings.

Best Practices According to Microsoft

According to Microsoft, these are some best practices to follow:

■

Set the maximum password age for passwords to expire every 30 to 90 days,

■

If the “Enforce password history” selection is used, be sure to set a minimum password age.

Account Lockout Policies

The account lockout policies are as follows:

■

Account lockout threshold option (number of invalid logins before lockout)

■

Account lockout duration (amount of time locked out)

■

Reset lockout counter after n minutes

Figure 6.8 depicts the Account lockout settings in the management console for group policy.

Figure 6.8. The Account Lockout Group Policy

We’ll now discuss each of these options in more detail.

The “Account lockout threshold” option is used to set the number of invalid logins before the account is locked out. Valid settings are 0 (which is never lock out an account) to 999. Once an account is locked out, it needs to be unlocked by an administrator, or the “Account lockout duration” time needs to expire. The default is 0.

The “Account lockout duration” option is used to automatically unlock the account after a period of time. The time is in minutes. Valid settings are 0 (which is never unlock an account until an administrator resets it) to 99,999. This is especially useful for organizations that have busy administrators or no off-hours support.

The “Reset lockout counter after n minutes” option is used to determine how many minutes need to elapse before the failed logon attempt counter is reset. The range is 1 to 99,999. In order to use this setting, the “Account lockout threshold” must be set. The reset time must be less than or equal to the “Account lockout duration” (if the account lockout duration is set).

Using Password Policies

First, to use password policies in SQL Server 2005, password policies need to be enabled. This is accomplished by turning on password policies in SQL Server when creating a login.

Here is an example of creating a login for SQL Server using T-SQL, which will use the policies defined in the operating system:

CREATE LOGIN Robby with

 password=‘Test$12345’,

 CHECK_POLICY = ON,

 CHECK_EXPIRATION = ON

Figure 6.9 is an example of creating a login for SQL Server using SQL Server Management Studio, which will use the policies defined in the operating system.

Figure 6.9. Creating a Login That Uses Password Policy

When you are creating a login, be sure to check the “enforce password policy” checkbox so the login will adhere to the password policy rules defined in the operating system. This is a good idea unless there is a compelling reason not to. The same holds true with password expiration.

It’s possible to enable one or both of the settings, because they function independently of each other.

Best Practices According to Microsoft

•

Mandate a strong password policy, including expiration and a complexity policy for the organization.

•

If SQL logins are required, ensure that SQL Server 2005 runs on the Windows Server 2003 operating system and use password policies.

•

Outfit the applications with a mechanism to change SQL login passwords. This includes application logins.

•

Set MUST_CHANGE for new logins where practical.

Some Independent Advice

While group policy can make your environment more secure when it comes to using SQL logins, it’s still a better practice to use Windows logins wherever possible.

Account Lockout Policy

Now that you are familiar with GPOs and how to apply them, we will discuss a few policy settings that you may want to consider implementing, either at the domain level or with local GPOs. The account lockout policy (\Computer Configuration\Windows Settings\Security Settings\Account Policy\Account Lockout Policy) allows you to configure the number of incorrect passwords that a user can enter before being locked out of an account, how long the account stays locked out, and how long before the lockout counter will reset. The following recommended settings will provide the most security in an average environment:

Account Lockout Duration represents how long the account will stay locked out. Setting this to zero means that the account will stay locked out until an administrator manually unlocks it. This is the most secure option. However, even allowing the account to reset after as little as 10 minutes will serve to slow down a hacker who is attempting to brute force the password.

Account Lockout Threshold represents how many invalid passwords a user can attempt before locking out the account. A setting of three invalid logon attempts is usually considered adequate. If the number is too low, a simple typo could result in an account being locked out. If this is set to 0 (insecure), the account will never be locked out.

Reset Account Lockout Counter After determines how long before the invalid attempt counter is reset. The default setting of 30 minutes is usually adequate. A longer setting is considered more secure.

Figure 3.9 shows the account lockout policy setting and MMC console.

Active Directory Domain Services

Active Directory Domain Services (AD DS) stores information about users, computers, and other devices on the network. AD DS is required to install directory-enabled applications. The following are improvements made in AD DS functionality:

Auditing (log value changes that are made to AD DS objects and their attributes)

Fine-grained password policies (functionality to assign a special password and account lockout policies for different sets of users)

Read-only DCs (hosts a read-only partition of the AD DS database)

Restartable AD DS (can be stopped so that updates can be applied to a DC)

Database mounting tool (compare different backups, eliminating multiple restores)

User interface improvements (updated AD DS Installation Wizard)