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.

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!

System Daemons and Services

Windows servers have background processes that perform many functions, called services. Unix systems also have background processes that work in a similar manner that are called daemons. Regardless of what you call them, these processes, which are called background because they do not require interaction with the keyboard but instead execute on the computer waiting to perform some function, can introduce security problems when they are not needed.

You should become familiar with the background processes on any servers in your network and disable those that are not needed. For example, on Unix systems, there are many background daemons associated with the TCP/IP suite of protocols. Some systems might need all of these, whereas some might need just a few or none of them. It might be that you do need these services. It might be that they need to be configured properly prevent their misuse. You should read the dumentation that comes with your Unix or Linux system to determine the capabilities that these daemons provide and disable them on systems that do no need them.

For example, tftp (the trivial ftp transport application) is a stripped-down version of FTP. It is com and usually can be easily implemented in an EPROM. For this reason, it is useful in some devices need to download operating software from a host. However, note that unlike FTP, tftp has no acc control mechanisms. This means that a username and password are not used. Because there is no authentication, this can be a real security problem if it is not configured properly, such that it can used only for its intended purpose.

On Windows servers, you can use two programs that are provided with the Resource Kits to install or run almost any executable program or batch file as a service. These are INSTRV.EXE, which can be used to install an executable, and SRVANY.EXE, which can be used to make other kinds of files into services. On a server that has several users logging in frequently, you might want to make it a regular part of your routine maintenance to review the services running on the machines and disable or remove those that are not installed by the initial operating-system installation or those that did not come from products you have applied to the system.

To do this, you will need to keep an inventory of what runs on each server, but this kind of inventory information can be useful for other purposes, such as when you need to reinstall a server that has been destroyed by a catastrophic failure.

Removing Dead Wood

Every operating system comes with default options installed that you might not be aware of unless you have read the documentation carefully. For example, default user accounts might be created

when you install the OS or later install a product. For example, the GUEST account in Windows operating systems is installed by default. You should always disable or remove this account. The Administrator account is also a vulnerable target because it is present on all Windows Server computers from Windows NT through Server 2003. You cannot delete this account, but you can rename it so that the hacker's job becomes more difficult. Also, you shouldn't use the Administrator account on a regular basis. Instead, create individual administrative user accounts for each system administrator trusted to perform these high-level tasks. Then put them into the Domain Admins group to allow these users to exercise administrator privileges, while maintaining an audit trail of the actual users who performed certain actions. You should always use separate administrative accounts for your domain administrators. Never use the same account for domain administration as is used for regular user functions. Administrators should be logged in with administrative accounts only when performing activities that require elevated permissions. You can also use group policies to further restrict what each user can do.

Regularly review the user accounts that exist on the network. Use the auditing features provided to determine when an account has not been in use for a long period, and if you can find no reason for its existence, disable it. Maybe someone in another department did not notify you when a user was terminated, or maybe an account was created for an expected new employee or contractor who later changed his mind and did not come on board. New accounts such as these are typically created with a simple password and can leave gaping security holes in your network.

Old programs and files that are no longer needed, or the use for which you are not sure, are also easy targets to cause security problems. As a rule of thumb, if it's not needed, back it up to tape and delete it! If a user finds that something she needs is missing, she will tell you!

When installing a new application product for a user, be sure you know the capabilities of the application. Don't install unneeded optional features that will not normally be used. Read the documentation!