Restrict access to prevent insider hacks

WARNING: You can seriously hamper user ability to log on by setting the wrong user rights. Please do the following steps in a test environment.

You may download a printer-friendly version.

Checklist: Restrict access to prevent insider hacks

Step 1: Keep users out of systems that don't concern them.

You'll want to set file permissions, but before you do, quarantine users so they can only access and log on to a limited number of computers. To do so, open their account property

pages in Active Directory Users and Computers, select Account tab and click the Log On To button. Next click "The following computer" button, enter the name of a computer the user is

allowed to access and click the Add button. If users must have access to multiple desktop computers and laptops, simply add those computer names. This works well when multiple

people need to use any one of several computers in a lab or department.

If you want to keep an account from logging on at any computer, just enter the name of a non-existent computer. Setting log-on-to computers does not restrict users from accessing

data on other computers across the network. To limit network access, configure user rights.

User rights specify what a user can do on a computer. Set them in the default domain controller Group Policy Object (GPO) to limit access on domain controllers, and in GPOs

linked to organizational units when you want to impact a subsection of computers joined in the domain. User rights are located in the GPO under Windows Settings --> Security

Settings --> Local Policy --> User Rights Assignment.

Step 2: Restrict rights that directly impact computer access.

User rights configuration is similar to file permission settings; if the right is not granted, the user does not have it. The following rights directly impact access to computers and

should be limited.

• Access this computer from the network This right only allows identified user groups access to the computer. By default, the

Everyone group has this right, and may not want that. To restrict this right, add groups that should have the right to access the computer, and then remove the Everyone group. Be

careful not to lock out service accounts.

• Deny access to this computer from the network Remember, by default, if a user does not have the right to access the computer, he is

denied access implicitly. Use this right sparingly to define those accounts that should never, under any circumstances, access the computer from the network. By default,

Windows Server 2003 locks out the support_388945a0 account. You could use this right to prevent the local administrator account from being used on the network.

Step 3: Harden log on and deny logon rights.

Be careful handling log on and deny logon rights. Each right has an associated counterpart -- a deny user right. Use deny rights sparingly, usually only to manage those accounts that

should never have the right. Follow the table below for recommendations. User right Meaning Recommendation Allow log on locally If a user has this right, he can sit at the console and log on. Restrict access to all servers by adding groups that represent those authorized to configure or manage the server. Then remove the users group. Be cautious here. If the machine is a terminal server, locking up local log on is not the choice to make. The SUPPORT_388945a0 account is denied this right. Allow log on through terminal services If this machine is a terminal server, users need this right. Restrict terminal services to those users who are actually authorized to use the servers. Log on as a batch job Batch jobs are jobs that run in the background. They are often scheduled with the task scheduler. Limit this right only to accounts that might be used to run these types of jobs -- and then only if the accounts need it. Accounts used for SUPPORT_388945a0, local service and Internet Information Services-related (IUSR, IWAM and IIS) WPG (Microsoft Word for Windows vector graphics) are given this right. Don't remove these groups unless the tasks they perform are no longer necessary on these computers. Log on as a service Services also run in the background. Limit this right to services that may need it (by default the network service account is given this right). Ordinary users do not need it.

Windows Security Checklists offer you step-by-step advice for planning, setting up and hardening your Windows security infrastructure.
E-mail the editor to suggest additional checklist topics.

ABOUT THE AUTHOR:   Go back

Roberta Bragg is author of "Hardening Windows systems" and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. Click to ask Roberta a question or purchase her book here. Also, if you have specific questions or comments about any of Roberta's checklists, click to e-mail her directly. Copyright 2004

Reader Feedback

Allan A. writes: I have a couple of additions to your checklist:

1. Restrict the number of systems to minimize administration and the probability of configuration errors.

2. Train and educate all users to lock their PC when leaving it -- even when they are just leaving for two minutes. Administrators can setup PCs connected to a network to lock after a certain number of minutes. But between the time someone leaves a PC to the time the autolock is activated, another person can easily access files and folders on the network.

Rate this Tip To rate tips, you must be a member of SearchWindowsServer.com. Register now to start rating these tips. Log in if you are already a member. Digg This!     StumbleUpon     Del.icio.us    RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.