Windows NT Passwords and Policies

Windows NT enables the administrator to set certain parameters that control passwords and accounts. This is called the account policy for the domain. To view the defaults or make changes, select Account from the Policies menu in the User Manager for Domains utility.

The values you choose for these parameters should reflect the degree of security you want to enforce at your site. At the same time, you need to balance your concerns with the abilities of your users. For example, if you set a large minimum password size and a low value for the number of days it can be used, users might end up writing down passwords just to keep track of them.

These are the parameters you can configure here:

• Minimum Password Age and Maximum Password Age—The Minimum Password Age specifies the number of days that must elapse before a user is allowed to change a password. The Maximum Password Age is the number of days that a password can be used, after which the system will force the user to change it. Both of these parameters can be set to a value ranging from 1 to 999 days.

• Minimum Password Length—This is the minimum number of characters that must be used for a password. Too small a value will make it easy for hacker programs to guess a password. Too large a value will make it difficult for users to think up new passwords. This parameter can be set to a value ranging from 1 to 14, or you can permit a blank password (no password), although it is hard to imagine a network where you might want to allow, as a policy for every user in the domain, a blank password.

• Password Uniqueness—The system will keep a history list of passwords used by each user and will not allow them to reset their password to one that is still in the list. This prevents users from constantly reusing a few easy-to-remember passwords, which can be bad for security purposes. Set this parameter to a value from 1 to 24. Selecting not to keep a history list is probably not a good idea because many users will take advantage of this option, and eventually someone else will find out what their usual password is.

• Account Lockout—You can set up the system so that a user account is "locked out" after a number of failed login attempts. This can be used to prevent an unauthorized user from trying to guess a password for an account, as is done in the brute-force method by many hacker programs that simply go through a dictionary, trying every word until they crack an account. If you set a value for bad logon attempts, you also can use the Reset Count After field to a time value (in minutes). This field specifies the period of time during which the failed logon attempts are counted. The Lockout Duration fields can be used to permanently lock the account until an administrator intervenes, or to set a time in minutes that the account will be disabled. A good idea is to set a small value for the Lockout After parameter (3 to 5 is a good choice), while using a long lockout value. Thirty minutes to an hour will usually suffice to deter unauthorized users.

At the bottom of this dialog box, you can see two other check boxes. The Forcibly Disconnect Remote Users check box must be checked in order for the user to be disconnected from the server when he stays logged on past the authorized period specified in the Hours button of the user's Account Properties dialog box. If the second check box, User Must Log On in Order to Change Password, is checked, users will not be able to log on after their password expires and change it. The administrator will have to perform this function instead. If this box is not checked, after a user password expires the user still will be allowed to log on but will be required to change the password before performing any other function.

Detecting Failed Logon Attempts

User logon failures occur for many reasons. The most common reason is that users forget passwords or type them incorrectly enough times to trigger the account lockout mechanism. Because Windows NT allows you to create a single username and password logon for each user, the problem of multiple passwords is usually not a problem as it is some other networks.

The Windows NT Event Viewer utility, found in the Administrative Tools section along with the User Manager for Domains, can be used to check for failed logon attempts. This is the first place you should look when a user is having problems logging on to the domain or connecting to a resource on a remote server. The user might not be providing the correct password or might be trying a username for which there is no account. The Event Viewer keeps three log files: Application, System, and Security. It is in the Security log file that you will find messages that relate to logon attempts.

As you can see, successful logon and logout events can be tracked. These types of messages can be useful when you are trying to determine who was on the system, perhaps during off hours, when you are trying to troubleshoot security problems. The other messages can be helpful in quickly identifying what the problem is when a user cannot log on to a server or connect to a resource.

The security log file you can examine using the Event Viewer can be configured to track all successful and unsuccessful logon attempts. This includes users who log on locally at the computer, connections made through network access, and logons by special accounts that you set up to run services.

Windows NT does not automatically track events such as these. You must enable the types of events you want to audit before they will be recorded in the security log file.

Strategies to Minimize Logon Problems

The best way to solve a problem is to take all necessary measures to ensure that the problem doesn't happen in the first place. Although it is not possible to completely eliminate every source of failed logon problems, you can do a lot to keep your network users happy by taking a few precautions:

• Place a backup domain controller on every physical subnet—If a network link goes down, users can still be validated by the local BDC and continue to work with resources to which they can still connect. A BDC with enough available resources can simultaneously perform the same functions as any other Windows NT Server, so if you have a server on a subnet that is offering resources and it is not already overloaded, consider replacing it with a BDC and let it serve two roles. Remember, if the server is not already a domain controller, you will have to re-install the OS and select that option during setup.

• Enforce reasonable password policies—Some operating systems allow you to computer- generate random passwords that are very difficult to remember. If a user cannot remember a password, most of the time the user will just write it down somewhere, which can compromise security. If you force users to change passwords too frequently, they will most likely have a hard time remembering what the recent password is, unless they write it down somewhere. If you set the account policy lockout values too low, you will find that users get locked out because of simple typing errors, and the help desk will spend a lot of time unlocking these accounts.

• Keep track of user accounts—You can use a paper method or an electronic one such as a spreadsheet or database. Delete accounts for users who leave the company and create new ones for new employees. Getting rid of the dead wood will help avoid confusion when troubleshooting and will help keep the SAM databases down to a reasonable size.

• Never use generic accounts where more than one user logs in under the same username—Though this is a tempting idea because you have fewer user accounts to manage, it can be a security nightmare if something goes wrong and you are unable to use auditing measures to figure out the who, what, and when of the matter. Also, when more than one person is using the same account to log on, it takes only one person with fumble-fingers to incorrectly type a password a few times and lock an account, also preventing others who use the same account from logging in.

To fully understand how to troubleshoot problems with logons, you should make yourself knowledgeable about the Windows NT Event Viewer administrative tool.

Using a Shadow Password File of Unix and Linux

To plug the password security hole presented by the / etc / passwd file, a technique called a shadow password file is usually used. This file contains the actual passwords, also in encrypted format. However, the shadow password file is not world-readable, and permissions are set so that only the root account can access this file.

On many systems, the name of the shadow password file is /etc/shadow. Check your documentation to determine the exact path on your system. Also note that on some older systems (and a few current ones), you'll have to load an extra component to install the shadow password file capabilities. Keep up-to-date by consulting your vendor's Web site.

The contents of this file also can vary from one system to another. However, the following format contains the fields used in most implementations:

username:password:last:may:must:warn:expire:disable:reserved

The following list describes these fields:

• username—This field is used for the same purpose as it is in the /etc/ pa s swd file. It is the login name for this user's account.

• password—The user account password stored in encrypted format.

• last—The number of days, since January 1, 1970, that the password for this account was changed.

• may—The number of days that must pass before the password for this account can be changed.

• must—The number of days after which the password for this account must be changed.

• warn—The number of days before the password expires to warn the user about the upcoming password expiration.

• expire—The number of days that must pass before the account password expires and the account becomes disabled.

• disable—The number of days, since January 1, 1970, that the account has been disabled.

• reserved—This field is reserved for future use.

As you can see, using a shadow password file gives you additional control over accounts, such as setting password expiration values. It also gives you informational fields (such as last and disable that can be used when managing user accounts.

The /etc/groups File

This file contains a list of user groups and a numerical value used to identify the group. The syntax for entries in this file is as follows:

groupname:grouppassword:groupID:username1,username2

• groupname—A name associated with the group. Using a meaningful name can help you simplify user administration.

• grouppassword—Yes, you can place a password on a group, but this is generally not done. Instead, this field is usually left blank.

• groupID—This is the group's ID number, which is used by the operating system to identify the group. It is often referred to as the GID. This number can range from 0 to 32,767, and the numbers 0 to 10 are generally reserved for system groups. For example, in most Unix implementations, the root user has a GID of zero.

• usernamel,username2 . . . —This is a comma-delimited list of members of the group. Separate each using a comma.

Users can be members of more than one group. If this is the case, the first group is the user's primary group, and the GID of this group is used when files are created or saved. Users can use the groups command to view the group(s) of which they are a member. The command chgrp can be used to change the current default group.

Assigning User Rights for Windows 2000, Server 2003, and XP

Users who are logged in to a Windows 2000, Server 2003, or XP computer can be granted rights by the administrator of the computer. If the user logs in to a domain account instead of the local computer, a domain administrator can manage these rights. Rights granted to an account that resides on an individual Windows computer protect access to resources on that computer only. The security information for the computer is stored locally, in the Security Accounts Manager (SAM) database, and applies only to resources on that local system.

Accounts that are created on a domain controller can be used when assigning user rights to resources on computers throughout the domain. And, by placing users into groups, you can easily manage a number of users who need the same access to resources or the same rights. This is done by granting the rights to the group, instead of individual users. If a user needs access to resources that are not granted by the group membership, you can place the user in more than one group. Because groups enable you to simplify granting rights to users, the following discussion will concentrate on those rights.

Starting with Windows 2000, most Administrative Tools are snap-ins for the Microsoft Management Console (MMC). By using the MMC to create management tools, you'll find it easy to switch from one MMC console to the next, without having to relearn the mechanics of the particular utility. For example, when using MMC you'll find two panes on the screen. The left pane contains a tree of objects that can be managed. An Action menu presents you with functions you can perform. The right pane is used to display different kinds of information, based on the particular utility and the actions you take. The MMC allows you to create new utilities by installing a snap-in that is appropriate for the functions you need to perform. However, most of the tasks you will use to manage thecomputer or domain have already been set up as an MMC application. Other snap-ins, which are used for more sensitive operations, such as altering the Active Directory schema, must be created by installing the snap-in.

Windows NT defined certain basic rights you could grant to a user account, as well as a set of rights that were granular. The basic rights were simply combinations of these granular rights. In Windows Server 2003, rights have been divided into two categories. These are logon rights and privileges. Logon rights are few in number, and can generally be used to manage most users or groups.

These logon rights are listed here:

• Allow log on through Terminal Services—Enables a user of a computer to log on using Microsoft Terminal Services. Essentially, a Terminal Services client runs programs on a server designated to supply this service, and the Terminal Server client computer displays the GUI interface for the application. This enables you to use older computers with fewer resources (such as memory or processor speed) to be used in your network.

• Allow log on locally—Enables a user to log on locally at a workstation or server; that is, to log on sitting at the workstation or computer, not using a network connection. Generally, administrators are the only users who can log on locally at a server.

• Access this computer from a network—Enables a user to log on to the computer from the network. In other words, this gives the capability to make a network connection, such as to access a file share on the computer.

• Log on as a batch job—Allows a user to submit a batch job (using the task scheduler) that will run under the user's account. Unless you deny this right, the default allows users to submit batch jobs to run in the background. Batch jobs are used to perform specific functions at a certain time, unlike services that run in the background and respond to certain system or user

events.

• Log on as a service—Thisright allows the user to start a service using his or her account. A service is a process that runs in the background continuously.

• Deny log on as a batch job—Preventsan account from running a batch job on the computer.

• Deny log on as a service—Prevents an account from being used to run a service (a background process that runs without a GUI interface).

• Deny log on locally—Isthe opposite of the Allow log on locally right. This right overrides the Allow log on locally right.

• Deny access to this computer from network—Isthe opposite of the Access this computer from the network right. This right overrides the Access this computer from a network right.

• Deny log on through Terminal Services—Isthe opposite of the Allow log on through Terminal Services right.

System Daemons and Services continue…

Delegating Authority

In a network of any size other than a simple workgroup, it is usually necessary to delegate authority to other administrators or middle-level management personnel. When you find that you must create accounts that have privileges to perform administrative functions, do not give carte blanche access to every account. Keep track of the exact functions an account will be used for, and grant only the access rights and permissions needed.

For example, if an operator will be performing backup functions on a server, he does not need to have full rights and privileges on the server. Under Windows Servers, you can place the user's account into the Backup Operators user group to give him the capabilities he needs, without compromising all files on the system. If you have users who must be able to add or modify user accounts, check the operating-system documentation and give the users access only to the resources and data files they need.

User Accounts

Generic accounts might seem like a good idea at first thought, but they provide nothing in the way auditing. If you simply let one or more users share the root account on a Unix system, or the Administrator account on a Windows server, you will have no way of determining tracking, and resolving who did what when something goes wrong. Indeed, because you can grant the same capabilities to any new account you can create, why not do so?

Give each user who requires elevated capabilities her own account, and grant the necessary privileges to the account. This way you can track each user to be sure she does not abuse her account or use it in a way you do not expect.

When you have more than one user using the same account, there is also the likelihood that the password will be compromised and someone who is not authorized to use the account will do so.

Application Servers, Print Servers, and Web Servers

One particularly common error you can make is to put all your eggs in one basket. Instead of using one server to provide print services or file services or Web services, many administrators use one server to provide all three. This is not necessarily a good idea.

Specialized servers can limit the damage that can be done by intruders and also can make it easier to delegate authority so that a particular administrator can concentrate on a limited set of functions for a certain server. Web servers are particularly prone to attempts by hackers to intrude onto your network. New applications and technologies are being developed and deployed all the time, and the newer they are, the more likely it is that they will have bugs or other loopholes that make them more risky than other applications that run on the network.

Placing sensitive data files on a Web server simply because it is convenient to use the machine's resources is not a good idea if it is also being used as a Web server. Make it more difficult to get at these files by dedicating a file server computer to them instead.

Delegating servers is almost like delegating authority to users. When you divide up resources and partition them into manageable groups, you make it less likely that an attack on one object will result in damage to all objects.

Denial of Service (DoS) attacks are very common on networks now. This kind of attack can be done by a malicious person who takes advantage of a known weakness in a protocol or an implementation of a particular service. One common mistake that administrators make when setting up an FTP site is to place it on an ordinary server.

For example, you might want to have an FTP server that allows customers to log in to your system and download information, patches, or other files. You also might want to be able to let them upload files or messages to your site. If you are going to allow anonymous FTP access, be absolutely sure that the service is configured so that it can access only a dedicated disk or set of disks. Do not allowanonymous access to an FTP service that writes to a system disk or a data disk that is important in your network. It is quite easy for an outsider to simply fill up the disk with meaningless data, causing a system to lock up or crash, depending on the operating system. If an important data disk becomes full, it can cause an extended period of downtime, putting employees out of work for hours while yo try to first determine the cause and then remedy it!

Physical Security Measures

Preventing unauthorized access to resources means that you must first prevent unauthorized access the physical components that make up the network. This includes user workstations, servers, netwo cables and devices, and so on. After the network connection leaves your physical area, such as when you connect to an outside Internet provider, you lose control over the physical aspects of the network. At that point, you must rely on other techniques, such as encryption or tunneling, to mainta security. However, the equipment over which you have control should be closely monitored to en that no one is tampering with anything in a manner that might serve to defeat the security policy effect at your site.

Locking the Door

As silly as it might seem, the simple door lock is an often-overlooked security device. You wouldn't leave your front door at home unlocked all the time, would you? The servers in your network that hold valuable or sensitive data should not be sitting out on a desktop or in an unlocked room where anyone can access them. Routers, hubs, switches, and other devices should be similarly protected. Wiring closets and computer rooms should have a lock on them or be protected by some sort of mon itoring on a 24-hour basis. If you have a round-the-clock operations staff, you might not need to lock the computer room. But if that staff consists of only one person during any particular period, get a lock for the door! Ideally, access to these secure areas will be tracked and logged, such as through employee badge readers. With very sensitive systems, you may even want to go as far as securing physical access through biometric authorization systems. Biometric systems, though still in their infancy, can help ensure that someone cannot gain access to a secure area simply by borrowing or stealing a physical token.

Backup media, such as tapes or writable CDs, should be treated the same as live data. Don't back up a server or your own personal workstation and then leave the tape cartridge or CD lying on the desk or in an unlocked drawer.

Uninterruptible Power Supply (UPS)

Keeping data secure can mean keeping it out of the hands of those who are not permitted to view it. It also can mean keeping the data safe from corruption. As more and more business-critical information is being committed to electronic form, it is important to take steps to be sure that it is not unintentionally compromised. A good UPS will p for itself the first time you have to spend daysreconstructing a database or reinstalling programs that become unusable due to a power outage or another problem of this sort.

Most computer operating systems have features that will work with a UPS so that the UPS can perform an orderly shutdown when it detects that power has been lost. If you are using a battery-backu UPS that has only a limited supply of power, an orderly shutdown can save a lot of problems when compared to a system crash.

Disposing of Hardware and Media in a Secure Manner

When you upgrade your network and bring in new workstations or servers, it is a generous thing to give employees, or an organization such as a school, your old equipment if it is still usable. However, you should establish a policy which dictates that all hard disks are to be erased and, when appropriate, a legal copy of the operating system reinstalled on it. If you leave important information on a computer you give away, don't be surprised when you see it again.

There is also the legal aspect to this. If you give away an old computer system, do you have the legal right to keep the software packages and install them on a new system? Probably not, unless you have a site license or another license that allows you to do so. For that reason, do not give away a computer that has applications installed on it unless you intend to give away the software packages also.

Disposing of used floppy disks, backup tapes, and tape cartridges also poses a potential security threat. It is better to destroy these information carriers than to give them away without being absolutely sure that you have purged them of any recoverable information. A bulk magnetic eraser can be a good security tool to use before disposing of this kind of stuff.

The Two Sides of Security

Locking the computer-room door is a preventive measure intended to keep out those who have no business being there. Preventive measures should be taken for software access mechanisms also. However, no matter how good you are at putting into place the access control mechanisms to protect resources, there is always going to be someone who will try, and possibly succeed, in breaking through. For this reason, you also must be able to keep audit trails of events on the network so that you can determine whether someone is trying to break your security, or whether indeed they have done so.

Before the Fact: Controlling Access

Controlling access to the network is done by several common mechanisms:

• User accounts and passwords

• Physical identifiers

• Resource protections

In many operating systems, the concept of a resource owner is important in this scheme. For example, OpenVMS and Windows 2000/Server 2003/XP keep track of the user who creates a resource, such as a file. That owner is able to change the protections applied to the file and can grant others the permissions needed to use the file. To a lesser degree, the same can be said for Unix/Linux operating systems.

Identifying Users

In a homogeneous network in which only one user account and password is required for access to permitted resources throughout the network, system management is not usually a complicated matter. Windows 2000/XP and Server 2003 allow for the creation of areas of control, called domains, that operate as security boundaries. Users in a domain can be granted access to resources on any computer, either server or workstation, that the network administrator wants to give them. In addition, trust relationships can be established between domains when administrators cooperate, making it possible for the user to still use only one username and password to connect to resources throughout the network. From Windows 2000 and more recent Windows versions, group policies can be used to further control access to important resources