Windows 2000 Quick Fixes By Jim Boyce December 2000 0-596-00017-0, Order Number: 0170 304 pages, $29.95

Chapter 12
Users, Policies, Certificates, and Security

As privacy concerns grow, security and intrusion protection become increasingly important topics for many people. This chapter provides answers to questions about a broad range of security-related topics.

For example, you'll learn in this chapter how to prevent your email from being forged and assure the recipient of its authenticity. Encryption and digital signatures are also covered in detail, including how to use digital signatures for multiple IDs and ensuring that a digital signature on an incoming message is valid.

Certificates play an important role in Windows 2000 security, and this chapter provides solutions for the more common issues you'll face regarding certificates and Certificate Authorities (CAs). For example, you'll learn how to obtain certificates from a CA and how to move certificates from one computer to another.

Sharing is another topic covered in this chapter. You'll learn how to monitor the users who are accessing your computer across the network as well as the resources they are using. If you're sharing your computer with others, you'll find ways to restrict the tasks a user or group can perform, prevent modification of the registry, and otherwise limit the changes that can be made to your system, whether locally or across the LAN.

The chapter covers additional security topics as well, including how and why to rename the Administrator and Guest accounts, control driver installation, prevent a system shutdown by unauthorized users, and control system behavior when a smart card is removed.

Protect authenticity of your email

Using a certificate to secure your email prevents someone from impersonating you to send forged email and also assures the recipient that the message is really from you. Whether you are transmitting important documents or simply want to let recipients know your email is authentic, digital signing through a certificate is the way to go.

There are two phases to securing your email. First, you need to obtain the required certificate. Second, you need to configure your email client to use the certificate for digital signing.

Obtain a certificate from a Certificate Authority (CA)

Before you can apply a digital signature to a message, you must first install a certificate that supports that function. You can obtain a certificate from a third-party CA like VeriSign or Thawte (which is now owned by VeriSign). The following explains how:

TIP:  

Check with your system administrator before obtaining a certificate from a third-party CA. Your network might include an enterprise or standalone CA capable of providing the certificate to you.

1. Connect to the CA's web site, such as http://www.verisign.com or http://www.thawte.com. You also can connect to http://www.microsoft.com/windows/oe/certpage.htm for additional CA choices.
2. Check the site for a link for personal certificates, specifically personal email certificates.
3. Click the link and follow the instructions provided to fill out the required form. Generally you'll need to have a credit card on hand to purchase the certificate.
4. Depending on the CA, you might receive your certificate immediately, or you might have to return to the site after your information is verified. In either case, the site will lead you through the steps to install the certificate through your browser. After the certificate is installed, you can begin using it to send messages.

Send digitally signed messages with Outlook Express

After you obtain the required certificate, it's easy to send digitally signed messages in Outlook Express. It requires only a few extra steps:

1. Compose the message (or reply to an existing message), and in the message window click the Sign button or choose Tools Digitally Sign.
2. Send the message as you normally would. If the certificate is not installed properly, you'll receive an error message and won't be able to send the email.

Send digitally signed messages with Outlook

Sending a digitally signed message with Outlook is just as easy as with Outlook Express, but the process is slightly different:

1. Compose the new message or reply to or forward an existing message.
2. In the message window click the Options button or choose View Options.
3. Select the option "Add digital signature to outgoing message," then click Close.
4. Send the message as you normally would.

Reading signed messages

You can read a digitally signed message just like an unsigned message. Just open it as you would an unsigned message. If the sender's digital ID has expired or the message has some other security-related problem, a warning message appears, giving you the option of viewing the message or not.

Encrypt email so only the recipient can read it

Although adding a digital signature to an email message helps validate the message, it doesn't prevent someone else from potentially viewing the message. You can encrypt messages for further protection, preventing unauthorized recipients from viewing them.

In order to view an encrypted message that you send, the recipient must have a copy of your digital ID with your public key. Similarly, for you to read an encrypted message from someone else, you need his digital ID. There are a couple of ways to obtain it.

Adding IDs of senders to your address book for signed messages

The easiest way to obtain a required digital ID is to exchange digitally signed messages. If someone else will be sending you encrypted messages, have him send you a digitally signed message, which will include his digital ID. If you'll be the one sending encrypted messages, first send the recipient a digitally signed message so he'll have your digital ID.

In either Outlook or Outlook Express, when you receive a digitally signed message, the digital signature of the sender is automatically added to your address book unless you've turned off that feature. Here's how to re-enable it in Outlook Express:

1. In Outlook Express, choose Tools Options.
2. Click the Security tab, then click Advanced.
3. Select "Add sender's certificates to my address book," then click OK. Click OK again to close the property sheet.

You can configure the same behavior in Outlook if you're using Outlook in Internet mail mode (but not in corporate workgroup mode). Here's how:

1. In Outlook, choose Tools Options.
2. Click E-mail Options on the Preferences tab.
3. In the E-mail Options dialog box, select "Automatically put people I reply to in," then click Browse to place the addresses in a folder other than the default Contacts folder.
4. Click OK, then OK again.

If you have a message in Outlook Express whose sender you'd like to manually add to the address book (along with the digital ID), right-click the message and choose Add Sender to Address Book. In Outlook, open the message, right-click the sender's email address, and choose Add to Contacts.

Obtain the public key from a CA

If you can't get a digitally signed message from the sender prior to receiving an encrypted message, you might be able to obtain the public key from the sender's CA. Point your browser to the sender's CA and follow the prompts provided by the CA's web site to obtain the other user's public key.

Configure digital IDs for one or more email accounts

You can theoretically use the same digital ID for several different email accounts. However, many email clients only recognize the first email address in the certificate, which is a potential problem. Ideally you should obtain a certificate for each account. After the certificates are installed on your computer (through the web browser), you can assign them to individual accounts.

Assign a certificate to an account

You assign a certificate to an email account through the account's properties. Use the following procedure to assign certificates to accounts in Outlook Express:

1. In Outlook Express choose Tools Accounts.
2. Select an account and click Properties.
3. Click the Security tab.
4. Under Encrypting Preferences, click Select, choose the certificate you want to use with the account, and click OK. Click OK again and then Close to finish.

Verify that the digital signature attached to an incoming message is valid

The presence of a digital signature in a message doesn't guarantee that the sender's certificate is valid. The certificate could have expired or been revoked. You can configure Outlook Express to use revocation checking to automatically check the status of a digital signature. Revocation checking causes Outlook Express to automatically submit a status request to the sender's CA to verify the current status of the certificate. The CA then responds with the certificate's status so you'll know whether the ID is still valid or not. Keep in mind that your computer must be online to perform revocation checking.

Use revocation checking

Follow these steps to configure revocation checking in Outlook Express:

1. In Outlook Express, choose Tools Options.
2. Click the Security tab and click Advanced.
3. In the Revocation Section, choose "Only when online."
4. Click OK, then OK again.

Move certificates to another computer

If you use two or more computers, such as a primary computer at the office and one at home or a notebook for travel, you might want to have your certificates on each one. This simplifies sending and receiving digitally signed or encrypted messages, enabling you to perform those tasks on each machine. You don't need to obtain separate certificates for each computer; you just need to export the certificates to a file.

Export and import certificates

You can export certificates from Internet Explorer, Outlook Express, or the Certificates MMC console. In all cases, Windows 2000 uses the Certificate Export Wizard to accomplish the task. The result is a certificate file that you can copy to and import onto the other computer(s).

Here's how to get your certificates onto a second computer:

1. In Internet Explorer, choose Tools Internet Options, click the Content tab, and click Certificates.

In Outlook Express, choose Tools Options, click the Security tab, and click Digital IDs.

In the Certificates console, open the branch Certificates\Current User\Personal\Certificates.

In IE or OE, select the certificate you want to export and click Export. If you're using the Certificates console, right-click the certificate and choose All Tasks Export.

2. Click Next after the Certificate Export Wizard starts.
3. Choose Yes, export the private key, and click Next.
4. Accept the default settings for Export File Format and click Next.
5. Specify a password to protect the certificate file and click Next.
6. Specify a filename for the certificate and click Next, then click Finish.
7. On the other computer, follow step In Outlook Express, choose Tools Options to access your certificates. In IE or OE, click Import to start the Certificate Import Wizard. If using the Certificates console, right-click in the right-pane and choose All Tasks Import to start the wizard.
8. Click Next after the wizard starts. Specify or browse to the path where the certificate is stored, select it, and click Next.
9. Specify the password entered in step Specify a filename for the certificate and click Next, then click Finish. and click Next.
10. Click Next when prompted for the location of the certificate (let Windows 2000 place the certificate for you automatically), then click Next again.
11. Click Finish.

Keep track of who is using your computer's resources across the LAN

Even if you trust the other users who have the ability to access your shared resources, you might still concern yourself with who is using which resources, and when. For example, keeping track of remote connections can alert you to access by unauthorized users.

You can use a couple of different methods to track connections and resource use: actively monitoring connections or using auditing.

View connections dynamically

You can use the Computer Management console to view the current connections and files opened by those connections. While this requires that you take an active role (therefore not the easiest method, particularly if you're busy), you can see the current connections at a glance. Here's how:

1. Right-click My Computer and choose Manage to open the Computer Management console.
2. Open the System Tools\Shared Folders\Sessions branch. Current connections are shown in the right pane (see Figure 12-1).
3. Open the System Tools\Shared Folders\Open Files branch to view open resources by connection.

Figure 12-1. You can view and terminate connections through the Computer Management console

Configure auditing

Auditing is a better method than manually monitoring connections because it's always monitoring even when you can't and maintains a record of access. If you have a problem with an unauthorized user accessing your computer, it's imperative that you have a record of the date, time, and other particulars.

When you turn on auditing, you direct Windows 2000 to monitor certain types of events and log those events to the Security event log. But, turning on and configuring auditing is just the first part of the picture. You also need to actively monitor the logs to keep track of events. We'll take a look at that aspect shortly.

In order to monitor resource access, you first need to enable the appropriate audit policy. Here's how:

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the Local Policies\Audit Policy branch.
3. Double-click "Audit object access," select both Success and Failure, and click OK.
4. Close the Local Security Policy console.

TIP:  

You probably realized by looking at the Audit Policy settings that you could audit several other types of events. Some of the other audit policies are discussed elsewhere in this chapter.

Enable auditing for specific objects

In most cases, enabling the audit policy is all you need to do to begin auditing that event type. In the case of folder and file access, however, you must explicitly identify which folders and files to audit. So it's a two-phase process: enable folder and file auditing by enabling the object access policy, and then specify which folders and files you want to audit.

You configure auditing of folders and files through the Explorer interface:

1. Open My Computer (or Windows Explorer) and locate the folder or file you want to audit.
2. Right-click the folder or file and choose Properties.
3. Click the Security tab, click Advanced, and click the Auditing tab.
4. Click Add, select the user or group you want to monitor, and click OK.
5. In the Auditing Entry dialog box (see Figure 12-2), select the specific events you want to audit, then click OK.
6. Add any other users or groups as desired, then close the Access Control Settings dialog box.

Figure 12-2. Select events to audit from the Auditing Entry dialog box

Configure and monitor the Security log

After you enable and configure auditing, you need to begin monitoring the Security event log. You can use the Event Viewer console, located in the Administrative Tools folder, to view all of the system's logs. Monitoring the log is simply a matter of reviewing it periodically to scan the events stored in the log.

As audit events begin to pile up in your Security log, however, you might need to tweak the configuration of the Security log to enable it to hold more events, clear events automatically, and so on.

Follow these steps to configure the Security event log:

1. Open the Event Viewer console from the Administrative Tools folder.
2. Right-click Security Log and choose Properties.
3. Configure the log settings, including the maximum log size and what action Windows 2000 takes when the log reaches its maximum size. These options are generally self-explanatory.

Keep track of who uses your shared computer locally, and when

If you share a computer with other users and you're the primary user, you might want to keep track of who else is using your computer and when. You do so by auditing logon and logoff, which logs these events to the Security log. You can then monitor the Security event log.

Audit logon and logoff

Unlike with object access, all you need to do to make Windows 2000 start auditing logon and logoff events is to enable the appropriate audit policy:

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the Local Policies\Audit Policy branch.
3. Double-click Audit account logon events, select Success and Failure, and click OK.
4. Close the Security Policy Console.

TIP: 

The audit policy Logon Events tracks non-local authentication such as network use of a resource or a remote service logging on using the System account. You might want to enable this audit policy as well to track remote access to your computer.

Prevent someone from modifying your registry

It's possible for remote users to connect to your computer's registry from across the network and make changes to your computer's configuration. In some cases, this is a good thing--administrators can make needed changes or repairs to your system remotely. The ability for remote users to access and modify your registry remotely can, however, be a security risk, particularly if your local administrator account is compromised.

If you share a computer with other users, you might also be concerned that they could make unwanted changes to the registry. So protecting the registry locally is also a consideration. Auditing is a third line of defense that enables you to keep track of registry changes.

WARNING: 

Be careful when modifying the registry. An incorrect change can render your system unusable. You should make a backup of the registry through the Backup accessory before making any changes.

Disable remote registry access and modification

When someone tries to connect to the registry remotely, Windows 2000 checks the permissions of the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg

If this key doesn't exist, all users can access the registry remotely, subject to the permissions assigned to individual registry keys. Those permissions then determine what actions the remote user can take within the key (adding values, deleting values, deleting the key, and so on). If the key does exist, the permissions assigned to that key determine whether the remote user can gain access to the registry at all.

TIP:  

You should allow at least the local Administrator account the ability to connect to the registry remotely in case your system needs remote administration to fix a problem that can't be fixed locally (such as the inability to log on locally with the Administrator account).

You can prevent remote access to your registry by setting the permissions on the winreg key so that only the required local accounts have permission to modify the registry. Or you can restrict remote access by setting permissions to grant only those authorized remote users access to the registry. Here's how to set permissions on the winreg key:

1. Click Start Run, and enter regedt32 in the dialog box.
2. Locate and select the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg

3. Choose Security Permissions.
4. Use the Permissions dialog box to set permissions as needed on the registry key, granting access only to those users you want to authorize for remote registry access.
5. Click OK and then close the Registry Editor.

Apply permissions to registry keys

In addition to restricting remote access, you might want to configure permissions on various registry keys to restrict who can modify the keys locally. Here's how:

1. Click Start Run, and enter regedt32 in the dialog box.
2. Locate and select the registry key you want to protect, then choose Security Permissions.
3. Use the Permissions dialog box to assign permissions to the key as desired (see Figure 12-3).

Figure 12-3. You can configure permissions on individual registry keys with Regedt32.

Audit registry changes

If you allow remote editing of the registry or simply want to keep track of who is making registry changes and when, you should enable registry auditing. As with object access, you enable auditing of registry changes by enabling the appropriate audit policy.

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the Local Policies\Audit Policy branch.
3. Double-click Audit object access, select Success and Failure, and click OK.
4. Close the Local Security Policy console.
5. Click Start Run, and enter regedt32 in the dialog box to start the Registry Editor.
6. Select the key you want to audit and then select Security Permissions.
7. Click Advanced and click the Auditing tab.
8. Click Add and add the users and groups whose access to the registry you want to audit. Add the Everyone group to audit all registry access.
9. Close the Access Control Settings dialog box and close the Permissions dialog box.
10. Repeat steps Select the key you want to audit and then select Security Permissions through Close the Access Control Settings dialog box and close the Permissions dialog box to configure auditing for other keys and then close the Registry Editor.

Restrict what can be done on your computer

If you share your computer with others and you are the primary user, you might want to exercise some control over the tasks other users can perform when logged onto the computer. In a home office where the kids also use the computer, you're sure to want to apply some restrictions to the actions the kids can take.

Restrictions are easy to achieve in a domain environment because you can apply them on a group or user basis through group policies applied at the domain or organizational unit (OU) level. It isn't quite as easy without a domain, but it can be done. On a standalone computer in a workgroup, you can ensure different levels of restriction and protection through a handful of different methods, starting with user accounts and groups.

Configure user accounts and groups

First and foremost, you need to make sure the other users are not using your account. It's important that each user has a unique account to enable you to apply rights and permissions differently for them. Using unique accounts is also important if you want to audit logon, logoff, resource access, and so on. You can use groups to further segregate permissions and rights if you have many users who work on the same computer. Or create a shared account with the necessary permissions and rights for those users who require the same settings and restrictions.

You create user accounts and groups through the Users and Passwords object in the Control Panel. This object also gives you access to the Local Users and Groups console, which offers additional options for creating and configuring user accounts and groups.

Protect the filesystem by using NTFS

The next step you should take in protecting your system from unauthorized or unintentional access or changes by other local users is to apply appropriate restrictive permissions to your folders and files. Review the permissions of all folders to make sure other users have at most read permission in any folder where they should not be able to make changes, removing write, change, or delete permissions as necessary. Also, consider removing read permission (denying access) to any folders and files the other users should have no need to see or modify.

In order to configure local restrictions on folders or files, you must be using NTFS on the affected volumes rather than FAT. If your volumes are currently formatted as FAT, use the convert utility to convert them to NTFS. See Chapter 1, Installing and Booting Windows 2000, to learn how to convert a FAT volume to NTFS. Although a backup is always a good idea before any major filesystem change, the conversion process is safe and you should have no problems converting.

Apply restrictions through policies and rights

Perhaps the most useful means of restricting what other users can do on your computer is group policy. In a domain, group policies can be applied at several levels: domain, site, OU, and locally. At the domain, site, and OU levels, you have the ability to apply policy settings on a user- or group-basis. However, the local group policy is intended to apply to all users, but there's a little trick you can use to apply local group policy to selected local users. For example, you might give your account full access but considerably restrict what all other users can do.

You can use the local group policy to apply a number of different restrictions. The following list summarizes just a handful:

Hide drives in My Computer

Prevent users from accessing certain drives (or any drive) through My Computer. Doesn't affect the ability to access the drives through other means, such as a command console.

Hide My Network Places

Help keep other users from browsing the network.

Hide the Internet Explorer icon

Help keep other users off the Internet. You could also apply permissions to the Internet Explorer executable to prevent other users from running it.

Disable Add/Remove Programs

Prevent other users from adding or removing currently installed programs.

Disable changes to the taskbar

Prevent intended or accidental modification or deletion of toolbars on the taskbar.

Remove Run from the Start menu

Prevent users from bypassing restrictions you've placed on access to applications by starting programs through the Start menu.

Disable and remove the Shutdown command from the Start menu

Prevent other users from shutting down or restarting your computer, disrupting needed services such as Fax.

The additional restrictions you can apply are too numerous to detail here. Spend some time reviewing all the settings in the local group policy to decide which ones you want to apply.

You configure the group policy through the Group Policy console. As you work through the following steps, keep in mind that the changes you make will initially affect the Administrator account as well. Make sure you don't make any changes that will prevent you from logging back on as Administrator, opening the Group Policy console, and removing the restrictions for the Administrator account.

1. Log on as Administrator.
2. Click Start Run, and enter gpedit.msc in the dialog box to start the Group Policy console.
3. Open the User Configuration\Administrative Templates branch and change restriction settings as needed. The settings for each restriction vary from one to another.
4. Close the Group Policy console and log off, then log back on again as Administrator to apply the change.
5. Log off and log on as another user to verify that the restrictions are applied. Log off and then log on as each of the other users to whom you want to apply the restrictions.
6. Log on as Administrator and copy the file systemroot\System32\GroupPolicy\User\registry.pol to a backup location and name it userreg.pol. Copy the file systemroot\System32\GroupPolicy\Machine\registry.pol to the same backup location and name it machinereg.pol.
7. Open the Group Policy console and remove the restrictions applied in step Open the User Configuration\Administrative Templates branch and change restriction settings as needed. The settings for each restriction vary from one to another. In some cases, you might need to use the opposite setting from the one applied in step Open the User Configuration\Administrative Templates branch and change restriction settings as needed. The settings for each restriction vary from one to another. For example, if you selected Enable to apply a given restriction, choose Disable to remove the restriction rather than Not Configured, which applies no change to the registry.
8. Close the Group Policy console and then copy the backup userreg.pol file created in step Log on as Administrator and copy the file systemroot\System32\GroupPolicy\User\registry.pol to a backup location and name it userreg.pol. Copy the file systemroot\System32\GroupPolicy\Machine\registry.pol to the same backup location and name it machinereg.pol back to systemroot\System32\GroupPolicy\User\registry.pol, making sure to rename the file registry.pol. Copy the backup MachineReg.pol created in step Log on as Administrator and copy the file systemroot\System32\GroupPolicy\User\registry.pol to a backup location and name it userreg.pol. Copy the file systemroot\System32\GroupPolicy\Machine\registry.pol to the same backup location and name it machinereg.pol back to systemroot\System32\GroupPolicy\Machine\registry.pol, making sure to rename the file registry.pol.
9. Log off as Administrator and log on as one of the restricted users to verify that the restrictions are in place. Log off and then back on as Administrator to verify that the restrictions are not applied to the Administrator account.

As long as you didn't use your own non-Administrator account to log on in step 5, that account will not have the restrictions applied.

Prevent changes to your system

If other users share your computer, you might be concerned that they are able to make changes to it. In most cases, simply preventing the other users from logging on as Administrator will prevent them from making most changes. However, some changes are still possible depending on how you've configured permissions of folders and files, whether the Control Panel objects are accessible, and so on. You can use a combination of permissions and local security policy to prevent unwanted changes to your system's configuration.

Prevent changes to your system

The procedures for accomplishing the lockdown of your computer have been covered either in this chapter or in earlier chapters. The following list summarizes the tasks you can perform to lock down your computer and where to go in Windows 2000 to accomplish those tasks:

Use NTFS and apply permissions to folders and files to prevent access or changes

Use the convert utility to convert your FAT volumes to NTFS (see Chapter 1). Then apply permissions as needed to prevent other users from reading or changing folders or files that should be off limits to them.

Prevent other users from logging on as a member of the Administrator or Power Users group

Use the Local Users and Groups console (right-click My Computer and choose Manage) to change group membership so that other users belong only to the Users group.

Disable the Control Panel

Use the domain or local group policy to disable the Control Panel for all accounts other than your own and the administrator's. See the earlier section, "Apply restrictions through policies and rights," to learn how to apply local policies selectively.

Hide pertinent desktop icons

Use the domain or local group policy to hide any desktop icons to which other users should not have access.

Hide drives in My Computer

Use the domain or local group policy to hide the icons for any drives that other users should not have access to.

Restrict access to run command and command console

Use the domain or local group policy to remove the run command from the Start menu. Apply permissions to cmd.exe in the systemroot\System32 folder to prevent execution by any account other than your own and the administrator's.

Apply other restrictions through the group policy

Review all the settings in the Group Policy console to determine which additional restrictions you need to set to prevent changes to your system. See the earlier section, "Apply restrictions through policies and rights," to learn how to apply local policies selectively.

Can't eject a removable NTFS media unless you're logged in as Administrator

By default, Windows 2000 allows removable NTFS volumes to be ejected only by members of the Administrators group. This helps ensure that casual or unauthorized users don't inadvertently eject an important media from a system. If you need to give other users the ability to eject NTFS media, you can do so through a simple security policy change.

Configure the security policy

You can select which types of groups have the ability to eject NTFS media by modifying the local security policy. If the domain policy is defined, it takes precedence over the local policy.

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the branch Security Settings\Local Policies\Security Options.
3. Double-click the policy "Allowed to eject removable NTFS media."
4. Select the desired groups from the Local policy setting drop-down list. You can choose Administrators, Administrators and Power Users, or Administrators and Interactive Users.
5. Click OK and close the console.

Specify when you'll be prompted to change password prior to its expiration

By default, Windows 2000 prompts you for a new password 14 days prior to password expiration. However, you might want to change that period, particularly if you've changed the password age limit. For example, if you've decreased the maximum password age from its default of 42 days, you'll probably want to decrease the notification period as well. Or perhaps you don't want to be prompted until just a few days before expiration. In any case, it's a relatively simple change.

Change security policy

The security policy defines how soon Windows 2000 prompts you to change your password before expiration. If domain policies are set, they override the local setting.

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the branch Local Policies\Security Options.
3. Double-click the policy Prompt user to change password before expiration.
4. Set the number of days prior to expiration that you want to be notified then click OK.
5. Close the console.

How (and why) to rename the Administrator account

Any hacker or intruder knows that on Windows 2000 systems the Administrator account gives him full access to the system if he can just guess, hack, or steal the password. Knowing the account name is a big step to breaking in, so changing the name of the Administrator account--particularly to something relatively cryptic--can go a long way toward keeping unwanted "visitors" out of your system.

Changing the Administrator account name is relatively easy. However, you should change it to something that you can remember, since you will have no other way to determine a forgotten account name unless you have another account on the system that is a member of the Administrator's group.

Change the Administrator account name

You change the Administrator account name through the Local Security Policy console. As a reminder, make sure you can easily remember the new Administrator account name, or make another account a member of the Administrator's group prior to changing the Administrator account name. This will enable you to log on with that account and view or change the Administrator account later if needed.

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the branch Local Policies\Security Options.
3. Double-click the policy Rename administrator account.
4. Type the new Administrator account name and click OK.
5. Close the console.

How to rename or disable the Guest account

Windows 2000 creates a Guest account automatically when the operating system is installed. Although the Guest account is disabled by default (unless you upgraded from a Windows NT installation that had the account enabled) and has limited rights and permissions, the account can still pose a security risk. If the account is configured incorrectly, it can serve as a "back door" to enable unauthorized access to your system.

You can take two steps to lock down the Guest account: rename, disable it, or both. Rename the account if you still want authorized users to be able to connect or log on using the Guest account. Disable the account if you don't need it.

Rename the Guest account

As with most security options, you rename the Guest account through the Local Security Policy console. Here's how to make that change:

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the branch Local Policies\Security Options.
3. Double-click the policy Rename guest account.
4. Type the new Guest account name and click OK.
5. Close the console.

Disable the Guest account

If you don't need the Guest account, it's a good idea to disable it. This prevents other users from logging on locally with the account or using it to connect remotely. You disable the Guest account through the Local Users and Groups console.

1. Right-click My Computer and choose Manage, then open the Local Users and Groups branch.
2. Double-click the Users folder to open it, then double-click the Guest account.
3. Select the option Account is disabled and click OK.
4. Close the Computer Management console.

Control what happens when your smart card is removed

If you use a smart card to log on to your computer, you should concern yourself with the implications of removing the smart card. For example, you should keep your smart card with you at all times for security reasons. This means that if you leave your computer, you should remove your smart card and take it with you.

By default, Windows 2000 takes no action when you remove the smart card. However, since you're probably leaving your workstation unattended, you should have Windows 2000 either lock the workstation or force a logoff.

Configure smart card removal behavior

You use the Local Security Policy console to specify the action Windows 2000 takes when you remove your smart card. If a domain policy is configured for this option, it overrides the local policy setting.

1. Open the Local Security Policy console from the Administrative Tools folder.
2. Open the branch Local Policies\Security Options.
3. Double-click "Smart card removal behavior."
4. From the Local policy setting drop-down list, select No Action, Lock Workstation, or Force Logoff, as desired.
5. Click OK and close the console.

Prevent unsigned drivers or services from being installed

If other users have administrative access to your computer they can install applications and device drivers. In most cases that isn't bad per se, but someone installing a noncompatible or buggy driver could wreak havoc with your system.

Microsoft has implemented a new feature in Windows 2000 called driver signing that enables a driver developer to certify that its driver has been tested and certified by Microsoft. This helps protect against incompatible and buggy drivers and services by ensuring that the driver has been through a testing and certification process. When you install a driver, Windows 2000 checks the driver to determine if it has been signed. If not, Windows displays a warning message and gives you the option of installing the driver anyway. You can change this behavior to prevent unsigned drivers from being installed. You can also configure how Windows 2000 handles other non-driver installation (such as services).

Prevent unsigned driver and service installation

You can configure two policies to define how Windows 2000 handles installation of drivers and non-driver applications such as services. As with most policies, if a domain policy is configured, it takes precedence over the local security policy. You use the Local Security Policy console to change the settings:

1. Open the Local Security Policy console and open the Local Policies\Security Options branch.
2. Double-click "Unsigned driver installation behavior."
3. Select "Do not allow installation," then click OK.
4. Double-click "Unsigned non-driver installation behavior."
5. Select "Do not allow installation," then click OK.
6. Close the console.

Keep another user from shutting down your system

If you share a system with other users, and if your system provides local or network services that need to be up all the time, you might need to prevent other users from shutting down the system. For example, if you use the Fax service to accept incoming faxes, shutting down the system means you'll miss faxes sent to you while the system is down. Or perhaps you share folders that need to be available all the time to other users on the network. Shutting down makes those folders unavailable. Preventing other users from shutting down the computer means they can log off, but they can't shut down the computer.

Prevent system shutdown

The ability to shut down the computer is one of the many rights that can be assigned to a group or user. By default, on a Windows 2000 workstation, members of the Users, Power Users, Administrators, and Backup Operators groups can shut down the computer. The most straightforward way to prevent others from shutting down the system is to limit the groups that have that right. For example, you could remove the right from the Users group, or even remove it from all but the Administrators group, depending on which users still need the ability to shut down the computer.

You configure rights through the Local Security Policy console. As with other security settings, rights can be inherited from the domain security policy; if one exists, it overrides locally defined rights. Here's how to reassign the right to shut down the computer:

1. Open the Local Security Policy console and open the Local Policies\User Rights Assignment branch.
2. Double-click "Shut down the system," then use the resulting dialog box to select which groups have the right to shut down the system. Deselect those groups (such as Users) that you do not want to be able to shut down the computer.
3. Click OK, then close the console.

Back to: Windows 2000 Quick Fixes