MCSE 70-293: Planning, Implementing, and Maintaining a Security Framework
Martin Grasdal , ... Dr. Thomas W. Shinder Technical Editor , in MCSE (Exam 70-293) Study Guide, 2003
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.
MCSE/MCSA 70–294: Creating User and Group Strategies
Michael Cross , ... Thomas W. Shinder Dr. Technical Editor , in MCSE (Exam 70-294) Study Guide, 2003
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
1.
From the Windows Server 2003 desktop, click Start | Administrative Tools | Active Directory Users and Computers.
2.
Right-click the domain you want to administer, and then select Properties.
3.
Select the Default Domain Policy, and dick the Edit button.
4.
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.
5.
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.
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.
Aaron Tiensivu , in Securing Windows Server 2008, 2008
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.
Warning
It's important to remember that only one set of GPO account and lockout policies applies to a domain. This functionality is unchanged from Windows 2000 Server and Server 2003. Although fine-grain policies can override the settings that are configured using a GPO at the domain level, they are not GPO-based.
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…
A Long-Awaited Password and Account Policy Solution
Fine-grain password and account lockout policy is new in Windows Server 2008. In Windows 2000 and 2003 forests, you could apply these settings only at the domain level. A single effective set of policy settings was enforced for all users. For many midsize to large organizations, this provided an unacceptable level of security. The limitation led to all kinds of complicated technical workarounds and the use of more complex domain and forest structures, which increased management costs.
Although fine-grain policies are certainly not as easy to use as traditional GPOs, they are a step in the right direction. Most companies will no longer require their previous workarounds, and Microsoft expects that many who adopted more complex domain structures will be consolidating and simplifying their forests. Fine-grain policies also represent a major departure from Microsoft's previous instructions to administrators to adopt a site-, domain-, and OU- based management style. They cannot be applied to any of these Active Directory container objects.
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.
Dr. Anton A. Chuvakin , Branden R. Williams , in PCI Compliance (Second Edition), 2010
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.
Figure 5.2. PCI Compliant Windows 2003 Account Lockout Policy
MCSE 70-293: Planning Server Roles and Server Security
Martin Grasdal , ... Dr. Thomas W. Shinder Technical Editor , in MCSE (Exam 70-293) Study Guide, 2003
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.
Predefined Templates
The Windows Server 2003 predefined templates are located in the %systemroot%/Security\Templates directory. The following templates are available:
■
compatws.inf Relaxes security settings on a workstation or server, so that otherwise incompatible applications have a chance of working.
■
DC security.inf Contains the default security settings for a domain controller.
■
hisecdc.inf Contains high-level security settings for domain controllers.
■
hisecws.inf Contains high-level security settings for workstations.
■
rootsec.inf Contains the default security settings for the system volume (%systemdrive%).
■
iesacls.inf Contains settings to lock down Internet Explorer.
■
securedc.inf Contains enhanced security settings for domain controllers.
■
securews.inf Contains enhanced security settings for workstations.
■
setup security.inf Contains the default security settings for a default installation of Windows Server 2003.
These templates are described in more detail in the following sections.
Compatws Template
The compatws template is used to provide users with access to applications that do not function properly with full system security in place. The compatws template relaxes user permissions so that programs are more likely to run without errors. It also removes any members of the Power Users group. Many administrators solve their application problems by adding users to the Power Users group. However, members of this group also have the ability to create users, groups, shares, and printers. Overall, this template erodes system security and should be used with caution.
DC Security Template
The DC security template is created when a server is first promoted to being a domain controller. It contains a number of default settings, including settings for the file system, Registry, and system services. This template allows you to reapply these default security settings. Registry keys and system services that have been added or modified since the initial installation may be overwritten, as may permissions on new files. Therefore, considerable planning should be done before applying this template to a domain controller in your network.
Hisecdc Template
The hisecdc template is used to apply high-level security settings to a domain controller. Using this template will cause the domain controller to require encrypted authentication. Using this setting will also prevent most pre-Windows 2000 computers from being able to communicate with the server, because the domain controller will require clients to communicate using NTLM version 2 (NTLMv2). Finally, this template will cause many applications to malfunction.
Hisecws Template
The hisecws template applies settings similar to those in the hisecdc template, but it is designed for use with workstations and servers that are not configured as domain controllers. When this template is applied to a computer, all of the domain controllers that have accounts for users that can log on to the client must be running Windows NT 4.0 Server with Service Pack 4 installed, Windows 2000 Server, or Windows Server 2003. Also, any domain controllers in domains that the client is a member of must be running Windows 2000 Server or Windows Server 2003.
Clients are also are unable to connect to computers using LAN Manager for authentication or from machines running operating systems earlier than Windows NT 4.0 Service Pack 4 using an account on the local machine. In addition, attempts to connect to a server running Windows NT 4 where the time on each machine has a difference of 30 minutes or more will fail. If the client connects to a computer running Windows XP, the time difference between them cannot exceed 36 hours.
The hisecws template also modifies settings to control memberships in security-sensitive groups. Once applied, all users are removed from the Power Users group, and only members of the Domain Admins group and the Administrator account are kept as members of the computer's local Administrators group.
As with the hisecdc template, applying the hisecws template will cause many applications to malfunction because of the enhanced security. This template should be very carefully tested before deployment.
Rootsec Template
The rootsec template is used to define security settings for the system volume. It is used to set permissions at the root of the system drive, so that original settings can be reapplied.
This can be particularly useful if the permissions on the system drive are inadvertently modified. This template can also be modified to apply the same root permissions on other volumes. In doing so, it will overwrite inherited permissions on child objects, but will not overwrite any explicit permissions on child objects.
Iesacls Template
The iesacls template is used to lock down security settings used by Internet Explorer (IE), which can be used to access data on the Internet or on a corporate intranet. Using this template, you can enhance security by enforcing stricter settings on Internet Explorer.
Securedc Template
The securedc template is used on domain controllers to enhance security while minimizing the impact on applications. This template also configures servers to refuse LAN Manager responses. Computers running operating systems such as Windows for Workgroups, Windows 95, and Windows 98 use LAN Manager to authenticate to servers. For these clients to be able to connect to a domain controller with the securedc template applied, the clients will need to have a patch or the Active Directory Client Extensions Pack installed on them.
Securews Template
The securews template provides the same settings as the securedc template, but it applies to workstations or servers that are not configured as domain controllers. It is designed to enhance security without impacting on applications that are running on the computer. This template also affects authentication, because it limits the use of NTLM by configuring clients accessing the machine to respond with NTLMv2 responses.
When this template is applied, the domain controllers that contain user accounts for those who will log on to the client must run Windows NT 4.0 with Service Pack 4 or higher, Windows 2000, or Windows Server 2003. Additionally, there are requirements dealing with time. If the domain contains Windows NT 4 domain controllers, the clocks between the domain controllers running this operating system must have their time synchronized within 30 minutes of one another. Computers also will not be able to connect to servers running Windows 2000 or Windows NT 4 if their clocks are off by more than 30 minutes from the server. Computers will not be able to connect to a Windows XP machine if their clocks are off by more than 20 hours.
Servers that have this template applied to it also have limitations. The server won't be able to connect to clients running LAN Manager and will need to be authenticated using NTLMv2. However, NTLMv2 canbe used to authenticate to Windows 2000 or Windows Server 2003 servers if the clocks on the client and server are within 30 minutes of one another. If the server is running Windows XP, the two machines must be synchronized within 20 hours of one another.
Setup Security Template
The setup security template is created when a computer is installed, and it varies from one machine to another, depending on whether its operating system was upgraded or a clean installation. Because of this, it should never be applied to a group of computers using Group Policy or manually to other systems, unless you have carefully reviewed its settings. This template allows you to reapply a system's default security settings. Use the DC security template for domain controllers, not the setup security template.
Dustin Hannifin , ... Joey Alpern , in Microsoft Windows Server 2008 R2, 2010
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
Policy
Description
Default Setting
Enforce password history
By enabling this policy, users cannot use any of the previously remembered passwords. For example, using the default setting of 24, the user cannot use any of the previous 24 passwords when setting a new password
24 Passwords remembered
Maximum password age
By enabling this setting, passwords expire every x number of days. The number of days configured here define how often the users will be forced to change their passwords
42 days
Minimum password age
By enabling this setting, passwords require to remain the same for x number of days. For example, the default setting of 1 day requires that a user keep the same password for at least 1 day
1 day
Minimum password length
By enabling this setting, users must include at least x number of characters in their passwords. The longer the password the more secure it is. However, the longer the password the harder it is to remember. You should find a happy medium for your network. Most security best practices recommend at least 8 characters, though some organizations are asking users to begin using passphrases opposed to passwords. This can increase the character count dramatically, thus increasing account security
Seven characters
Password must meet complexity requirements
By enabling this setting, users must create passwords that are considered complex. Complex passwords require that the password use characters from three of the following four sets of characters:
▪
Upper Case
▪
Lower Case
▪
Number
▪
Special Characters such as #, @, !
Complex passwords cannot contain part or all of the user's full name or username
Enabled
Store passwords using reversible encryption
This setting essentially stores passwords in a plain text format. This is to provide backwards compatibility with some legacy applications but is not recommended.
Disabled
Notes from the field
Multiple password policies
Windows Server 2008 R1 first introduced the ability to have multiple password policies in a single domain. This allows you to set up different password requirements assigned to different groups of users. For example, you can have a more strict password policy assigned to administrative-level accounts.
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:
1.
Open Server Manager.
2.
Expand the nodes Features | Group Policy Management | Forest: <your forest name> | Domains | <your domain name>.
3.
Right-click the Default Domain Policy and choose the Edit option.
4.
Expand the nodes Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies.
5.
Select the policy you want to modify. After making changes, close the Group Policy Management Editor. Changes will be automatically saved.
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.
Password Policies Explained
Password policies force the account to adhere to a specific set of rules. The rules can be broken down into two distinct types, one set of rules related to password policies, and another related to account lockout policies. The following sections detail each of these policies.
Some Independent Advice
Since group policies are usually controlled by the network administration group in most organizations, be sure to communicate with the appropriate teams in your organization before making any changes.
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).
Why Use Password Policies?
Using password policies in SQL Server 2005 will help to ensure that uniform security is enforced across all SQL logins. Password policies can be enforced at the domain level, the container level, or at the local machine level via group policy. Password policies are not a "silver bullet," but in today's society, any help keeping SQL server installation more secure is a good thing.
When you are establishing password policies in the organization, they will most likely be across all systems, including SQL Server and the Microsoft Windows logins. Group policy can help ensure uniform application across systems.
Shourtcut…
Using Group Policy
It may be more efficient to implement group policy at the Active Directory level. It makes sense to create a container in Active Directory for all of the SQL servers if there are a number of them in your organization, and apply the group policy at that level. While this is outside the scope of this book, it would be beneficial to learn more about Windows Group policy and Active Directory so the strategy can be implemented in the most efficient manner.
Operating System Requirements
In order to use password policies, SQL server 2005 needs to be running on Windows Server 2003 or later. SQL 2005 password policy functionality depends on the NetValidatePasswordPolicy application program interface (API), which is only available in Windows Server 2003 and later versions. Also, password policies need to be enabled for that machine via group policy. Password policies are part of Windows group policies. Group policies can be applied to different containers in Active Directory, as well as locally on the machine.
Some Independent Advice
Since group policies can affect other Windows services such as windows user passwords and passwords used by service accounts, be sure to completely test your changes in a test environment before making any changes to your production environment. It's very important to understand the impact of any changes you are going to make before making them.
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.
Eric Seagren , in Secure Your Network for Free, 2007
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.
Aaron Tiensivu , in Securing Windows Server 2008, 2008
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)
What Is New in the AD DS Installation?
AD DS has several new installation options in Windows Server 2008, including the following:
▪
RODC
▪
DNS
▪
Global Catalog (GC) servers
New OS installation options include Full Install and Core Server Install.
The first thing you must do when adding a Windows Server 2008 DC to a Windows 2003 forest is to prepare the forest for the Windows 2008 server by extending the schema to accommodate the new server:
▪
To prepare the forest for Windows Server 2008 run the following command: adprep /forestprep.
▪
To prepare the domain for Windows Server 2008 run the following command: adprep /domainprep.
It is recommended that you host the primary domain controller (PDC) emulator operations master role in the forest root domain on a DC that runs Windows Server 2008 and to make this server a GC server. The first Windows Server 2008 DC in the forest cannot be an RODC. Before installing the first RODC in the forest, run the following command: adprep /rodcprep.
Making sure the installation was successful, you can verify the AD DS installation by checking the following:
▪
Check the Directory Service log in Event Viewer for errors.
▪
Make sure the SYSVOL folder is accessible to clients.
▪
Verify DNS functionality.
▪
Verify replication.
To run adprep /forestprep you have to be a member of the Enterprise Admins and Schema Admins groups of Active Directory. You must run this command from the DC in the forest that has the Schema Master FSMO role. Only one Schema Master is needed per forest.
To run adprep /domainprep you have to be a member of the Domain Admins or Enterprise Admins group of Active Directory. You must run this command from each Infrastructure Master FSMO role in each domain after you have run adprep /forestprep in the forest. Only one Infrastructure Master is needed per domain.
To run adprep /rodcprep you have to be a member of the Enterprise Admins group of Active Directory. You can run this command on any DC in the forest. However, it is recommended that you run this command on the Schema Master.
0 Response to "Computer Locked Try Again in 60 Minutes"
Post a Comment