Multiuser systems are security holes in and of themselves. The simplest systems—those used by only one person—are the easiest ones to secure because there's much less diversity and variance of usage on the part of one person than there is on the part of many. Unfortunately, most of our IT environments require multiple user accounts, so the following section focuses on some prudent ways to lock down Windows systems, including Windows Server 2008 machines and associated client workstation operating systems.
Long passwords are more secure, period. As you might suspect, there are more permutations and combinations to try when one is attempting to crack a machine via brute force, and common English words, on which a dictionary attack can be based, are generally shorter than eight characters in length. By the same token, passwords that have not been changed in a long time are also insecure. Although most users grudgingly change their passwords on a regular basis when encouraged by administrators, some accounts—namely the Administrator and Guest accounts—often have the same password for life, which makes them an easy target for attack.
To counter these threats, consider setting some basic requirements for passwords. To set these restrictions on individual workstations and Windows Server 2008 member servers, follow these steps:
Open the MMC and navigate to the Local Security Policy snap-in. You usually access this by selecting Start → All Programs → Administrative Tools.
Navigate down the tree, through Security Settings, to Account Policies.
Click Password Policy.
Enable the "Passwords must meet complexity requirements" setting.
Change the "Minimum password length" to a decent length. I recommend eight characters. (I must note here that I prefer passwords longer than 14 characters, but I predict that you will encounter serious user resistance to such a move.)
Change the "Maximum password age" setting to a conservative setting. I recommend 90 days.
You can accomplish the same through GP if you have a Windows domain by selecting an appropriate GPO and loading the Group Policy Object Editor, as explained in Chapter 6. Keep in mind that changes to the domain password policy will affect all machines within the scope of the GP. The configuration tree within the Group Policy Object Editor remains the same.
New to Windows Server 2008 is the ability to define different password policies for different users. No longer do you have to set up distinct domains when you need different password policies to apply to specific users; with Windows Server 2008, you can apply specific password policies to users' accounts in global security groups.
To use this new feature, there are a few prerequisites software-wise. They include:
The domain functional level must be Windows Server 2008.
You must be a domain administrator to set a password policy. You can delegate this, however.
You must fully configure the password settings object, or PSO.
What is a PSO? The password settings object resides in the password settings container, which is unique to any given domain. The PSO has different attributes, which can in turn hold different values, for password and account lockout policies, like complexity and age requirements, maximum unsuccessful logon attempts before logout, and so on. The PSO can be linked to individual user accounts or groups, and these accounts can have multiple PSOs assigned to them.
The process to enable fine-grained password control and to enable access to PSO lacks a lot of finish; unfortunately, you have to go spelunking into the internals of Active Directory in order to enable this support. Before you embark on this procedure, I recommend generating a full backup of your system. Here is the process:
From the Start menu, type
adsieditand then click the resulting link at the top of the window called ADSI Edit.Right-click on ADSI Edit in the right pane, and from the context menu, select "Connect to."
Click OK in the Connection Settings screen.
In the left pane of ADSI Edit, expand the "Default naming context" past the first node and click on the CN=System node.
In the right pane, right-click on CN=Password Settings Container and from the New menu, choose Object.
On the resulting Create Object screen, select the only class listed (
msDS-PasswordSettings) and click Next.You'll be taken through a number of rather cryptic screens that contain attributes for which you need to provide values. For example, perhaps we want to create a special password policy that applies only to administrators. Table 7-1 shows these attributes, some suggested values that are relevant to our example, and an explanation of exactly what each value is. Continue through each of the steps, entering the values in the white box as requested.
Click Finish on the confirmation dialog.
If you expand the CN=System node in the left pane, and then click on CN=Password Settings Container, you'll now see the PasswordPolicyAdmins policy that we just created. This is your confirmation that the policy has been successfully created.
From this point all we have to do is to assign the new policy to most any combination of users and groups. To do so:
Right-click the PSO from within ADSI Editor and select Properties, and on the resulting screen, click the Filter button.
Select the following options: "Mandatory," "Optional," "Constructed," "Backlinks," and "System-only." Ensure that the "Show only attributes that have values" option is not selected.
In the list on the Attibute Editor tab, navigate to msDS-PSOAppliesTo.
Select msDS-PSOAppliesTo and click the Edit button at the bottom left of the screen.
The "Multi-valued Distinguished Name with Security Principal Editor" window appears. Click the Add DN button and then enter the security group, user, or any combination thereof that should be affected by this new password settings policy. You'll need to use the distinguished name, which is the LDAP version of a container name. You can have as many entries on this screen as you like.
Click OK.
Your new policy is now configured, deployed, and filtered on the appropriate security group (Table 7-1).
Table 7-1. Attributes, values, and descriptions (note minus signs)
Tip
One final note on passwords: encourage your users to use passphrases and not just passwords. This is a great way to enforce a 14-character minimum password length while still making it easy for your users to remember their codes. For example, suggest that they use something such as "My dog is named Molly!" as a password instead of something such as "jsx8q6sv8qtr3r". Tell your users to type their passwords in the password entry box as though they were typing into Microsoft Word or another common word processing program. Windows can accept it, and your users are more likely to remember it.
Three old-fashioned methods of gaining unauthorized access to a system are to attempt authentication using the following:
A well-known username (e.g., administrator)
A username not known but derived logically (e.g., admin)
A different password for the username on each attempt, repeating as often as possible
Windows can thwart these styles of attack using an account lockout policy, which will disable an account for a specified period after a certain number of unsuccessful logon attempts.
To set the account lockout policy, follow these steps:
Open the MMC and load the Group Policy Object Editor for an appropriate GPO, or navigate to the Local Security Policy snap-in.
Navigate down the tree, through Security Settings, to Account Policies.
Click Account Lockout Policy.
Set the "Account lockout threshold" to a reasonably small number. I recommend three bad login attempts.
Set both the "Account lockout duration" and the "Reset account lockout after" options to 15 minutes. This setting resists attack while not seriously imposing on users who just suffer from "typo syndrome."
Tip
As with password policy, you can configure account lockout policy at the local computer or domain level. However, because the password policies are domain dependent, the "local" level is in effect only when the computer is not logged on to the domain.
In addition to securing local accounts, the newer Windows platforms give you the ability to lock down certain rights and configurations on the local computer in addition to any domain security policy that might be configured. Several of the available options do little to thwart attacks, so in this section I'll cover the six most effective changes you can make to your local security policy.
You can enable all of the hardening suggestions in this section through the Security Options section of the Local Security Policy snap-in to the MMC. You can usually find this snap-in under Start, All Programs, and Administrative Tools. To get to the appropriate section, navigate the snap-in tree by selecting Computer Configuration, Windows Settings, Security Settings, and Local Policies. Then click Security Options, and the different configuration switches will appear in the righthand pane.
The instructions in this section assume that you have already loaded the snap-in and navigated to the appropriate section.
Windows allows access by an anonymous user to many shares and files using a null user account; this is a security hazard, of course. You still can enable anonymous access to files and directories by explicitly granting rights to the ANONYMOUS USER account in Windows inside the appropriate ACL. This setting merely disables that access by default, so you know exactly where connections are being made.
To fix this hazard, set Additional Restrictions for Anonymous Connections to "No access without explicit anonymous permissions."
Windows 2000 and Windows XP Professional machines come in a default configuration that allows you to shut down the system using the Shutdown ... button on the logon screen, so you might be familiar with this feature. However, Windows 2000 Server and Windows Server 2008 machines disable this out of the box. Despite the convenience factor of this feature, it's best to leave rebooting a machine to administrators.
Change "Allow system to shut down without having to log on" to Disabled to secure this.
Some users log on to the network and then don't log off for months. This is a prominent security hole, as when that user leaves her desk, she still is authenticated to the network with her credentials. Malicious people can use this to do destructive things: delete and transfer files, plant a "root kit" or backdoor program, or change passwords.
You can make automatic logoff work in two ways: first, each valid user needs to have a time when she is not permitted to log on. This can be sometime in the early morning, perhaps 3:00 to 3:30 a.m. Then, a change to the local security policy needs to be made so that when the user's logon time expires, she is not permitted to log on.
To set up a logon time restriction on a domain controller for an Active Directory-enabled domain, follow these steps:
Go to the Active Directory Users and Computers snap-in.
Expand the icon for your domain and click the Users container.
Right-click a user and select Properties.
Click the Account tab, and then click the Logon Hours ... button.
Select the appropriate region of time in the calendar block, and click the radio buttons to the right to either permit or deny logons during that time.
Click OK, and then OK once more to exit the user property sheet.
Tip
This option is available only for members of an Active Directory domain.
Now, make the change to the computer's local security policy. Inside the Local Computer Policy snap-in, change "Automatically log off users when logon time expires" to Enabled. If you do not have a domain, instead change "Automatically log off users when logon time expires (local)" to Enabled. This will work even if users have locked their workstations.
It's a good idea these days for a computer to authenticate itself to other computers during a communication. Otherwise, a technique called "spoofing" can be used, and a cracker's computer can pose as the remote end of a connection and receive potentially sensitive information. You can prevent this by using digital signatures. However, these are not pervasive; Windows compensates for this limited use by providing two options in the local policy: require it when possible, or require it, period.
I recommend requiring the signatures when possible on both ends of a connection (the RPC protocol refers to the requesting end as the "client" and the responding end as the "server," regardless of the systems' usual roles). Unsigned transmissions should occur only when signatures are not available, supported, or possible.
Warning
Be aware that this setting will probably break communications between Windows Server 2008 and Windows Server 2003 machines and older, less secure client operating systems, including Windows 95, Windows 98, and Windows ME. The SCW will set this policy for you and warn you of this.
To require digitally signed communication when possible, change "Digitally sign client communication (when possible)" to Enabled and "Digitally sign server communication (when possible)" to Enabled.
The logon screen is one of the most trusted aspects of a computer to a normal user. He trusts it enough that he gives his password and username, and then the computer trusts him, too, if all of that is correct and verified. A cracker can take advantage of this mutual trust by writing a program that runs as a system service—in other words, it doesn't need user privileges. The program will mimic the logon box, grab the user's input, and do something with it such as email the password to the cracker, save the credentials to a backdoor program data file, or any number of other nefarious things. However, pressing Ctrl-Alt-Del brings Windows to attention, and you get the authentic Windows logon and not a shell of one that a cracker creates. This easy step makes your system much more secure.
To require this keystroke to begin, change "Disable CTRL+ALT+Delete requirement for logon" to Disabled. (Yes, that's right. Microsoft uses some questionable terminology.)
By default, Windows displays the username of the last successfully authenticated person to use that particular system on the logon screen. This is giving away needless information, although some of your users are probably accustomed to it.
To disable the last username from being displayed, change the "Do not display last user name in logon screen" setting to Enabled.
Earlier in this chapter, I discussed setting password policies to prevent brute force attacks. Of course, changing passwords is a problem for some users who'd rather not be bothered with IS minutiae and simply would like to use their computers to be productive. With this policy setting, you can tell the system to automatically remind a user when his password will expire and prompt him to change it. Setting this value to 14 days gives a user ample opportunity to change his password because that is in excess of most scheduled vacations and business trips.
To enable the password expiration prompt, change the "Prompt user to change password before expiration" setting to 14 days at minimum.
Windows Server 2008 and GP allow you to configure security options that reside inside GPOs that will apply to groups of computers. GP can manage security settings throughout an Active Directory environment in seven areas. They are shown in Table 7-2.
Table 7-2. GP areas and descriptions
When you install Windows Server 2008, a default domain security policy is created. The default domain security policy is simply a set of configurations that apply certain security settings to all members of the domain: these can include security settings for displaying the username of the last user that logged on to a system, how long a password should be, whether workstations should digitally sign transmissions to and from a server, and so on. It's a simple task to use this default policy as a base and customize settings based on your individual implementation. Let's look at this default policy first, and then work through customizing it.
To view the default domain security policy, follow these steps:
Open the Group Policy Management Console.
Expand the tree in the left pane through your forest, Domains, your domain, Group Policy Objects, and find Default Domain Policy.
Right-click on Default Domain Policy and select Edit.
To view each default domain policy, drill down through Computer Configuration, Policies, Windows Settings, and Security Settings, and click Account Policies.
Look at the right pane. You'll see Password Policy, Account Lockout Policy, and Kerberos Policy. By clicking each, you can view or change its default configuration.
Figure 7-2 shows the default domain policy on a standard, out-of-the-box installation of Windows Server 2008.
The default domain controller security policy, like the default domain security policy, applies a common configuration to a group of computers, but this time the focus is only on domain controllers. Domain controllers often have special security considerations that ought to be addressed separately, and this default policy does that. Follow these steps:
Open the Group Policy Management Console.
Expand the tree in the left pane through your forest, Domains, your domain, Group Policy Objects, and find Default Domain Controllers Policy.
Right-click on Default Domain Controllers Policy and select Edit.
Drill down through Computer Configuration, Policies, Windows Settings, and Security Settings, and click Account Policies.
Look at the right pane. You'll see Password Policy, Account Lockout Policy, and Kerberos Policy. By clicking each, you can view or change its default configuration.
Figure 7-3 shows the default domain controller security policy on a standard, out-of-the-box installation of Windows Server 2008.
There is a special way in which account policies are distributed to domain controllers that deserves comment. All domain controllers in a specific domain will apply security policies established at the domain level regardless of where the actual computer object for that domain controller resides in Active Directory. This helps to ensure that consistent account policies apply to any domain account. All other policies are applied at the normal hierarchical level, both to domain controllers and to other workstations and servers in the domain. Only domain controllers are affected by this special exception. This is just a tip to remember when you're planning account policy distribution among your organizational units.
To view the effective security policy from a domain controller, complete these steps:
Choose Start, click Run, and type
GPEdit.msc. The Group Policy Object Editor will open.In the left pane, drill down through Computer Configuration → Windows Settings → Security Settings, and click Local Policies.
Now you can view the domain controller's effective security policy. When you're finished, close the Group Policy/Local Computer Policy snap-in. (When prompted to save console settings, click No, unless you've done something you want to hold on to.)
At this point, you have all the tools you need to begin pushing automated security configurations to clients running Windows 2000 and later. Note that all settings covered in this book, unless noted at the time each is presented, are fair game for distribution under GP.
With power comes complexity, and GP is no exception. Windows administrators have squandered away many hours of their lives on basic GP troubleshooting. Answers to quandaries such as, "Why isn't this policy in effect on this system?" or "I thought I turned off IPSec!" can be difficult to track down if your Active Directory is full of GPOs that are applied inconsistently, redundantly, and inappropriately.
To curtail your security policies and make them easier to locate, disable, change, and apply, try to follow these guidelines.
- Organize your policies logically and define boundaries to contain them
Although your Active Directory might be organized by geographic location, your system management needs might revolve around a different paradigm: for instance, you might need IPSec for all company executives' laptops, but they might not all be in your New York office. Or all middle managers in your corporation might require a customized version of Internet Explorer that doesn't lock them out from accessing the Internet, which might be the default configuration for all computers in the domain. The idea is to map out the kinds of restrictions you need, and then define boundaries to which those policies apply. This will make it easier to apply them to the target users and computers even if the geographical and managerial boundaries do not match.
- Inside those boundaries, configure policies that represent common values in your organization
Do you usually configure workstations in your finance department to lock a computer after three unsuccessful logon attempts? Does a particular domain in your forest need additional desktop restrictions—should they not be allowed to run the Control Panel, for instance? Change their wallpaper? Install software on their own? These are the kinds of policy sets that likely sound familiar. Group these together and create GPOs for each of these like sets of policy settings.
- Configure organizational units inside Active Directory that contain machines grouped according to similar roles or functions within an organization
This gets further into the granularity of your security policies. For example, Windows comes by default with domain controllers residing in a separate organizational unit in Active Directory. You might consider putting desktops, laptops, and servers into their own organizational units, which makes it easier to apply policies, such as requiring use of the EFS, only to laptops.
Now I'll present an understatement: it can require some work to configure GP correctly and effectively. The most difficult parts of the process are planning and laying out the policy settings; Windows takes care of the actual deployment to client computers, which is one of the features that makes GP a compelling management tool. This ease of deployment is a double-edged sword, however: it is equally simple to misconfigure an ACL or change a setting (anybody who has played with the "require signed communications" settings knows this all too well) and wreak utter havoc on your domain. The process also is made more difficult by the lack of an API, so you can't write simple automation programs to help you out. You have to go the long way.
Even more difficult sometimes is getting the big picture. That is to say, it is hard to see how your Active Directory layout and structure—which logically and traditionally have likely mimicked your organization's hierarchical personnel structure—can co-exist with GPOs, which seem to cross hierarchy boundaries and rely on other scopes of application. With careful planning, however, GP can overlay your existing directory structure and complement it with its own management boundaries.
Tip
GP configuration, structure, and operation are covered in detail in Chapter 6.