You can view all of Wes's network security advice here
Q: How can I prevent a domain user or computer from accessing all servers on the network? I only want them to be able to access one server.
A: One effective method of doing this would be to add the user to a group that you create (for example Server A Users) and then remove them from the domain users group. Next, make the group that you created a member of the appropriate local groups on the server to grant them the level of access you desire. For example, if you want them to be just a regular user, you can add the global group to the local "Users" group.
Q: How can I prevent certain users who are domain administrators from logging onto domain controllers?
A: That depends on the kind of user they are. If they are a member of a group that grants them rights on domain controllers (for example, Domain Admins) there really isn't a way to do that. If your domain is small enough, you could specify the list of computers they are allowed to login to, excluding the domain controllers, but I think this would rapidly become unmanageable (every time you add a computer, potentially you need to update the list of computers they can login to) as well as being rendered ineffective if the users in question are domain admins (they can always come in behind you and undo it).
Now, assuming that this is not a domain admin, the ability to logon to a domain controller is defined in the Default Domain Controllers Group Policy. You can view this by right clicking on the Domain Controllers OU in Active Directory Users and Computers and selecting "Properties". Click on the "Group Policy" tab, select the policy and click "Edit". Navigate using the Group Policy Object Editor to the following branch:
Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
In the right hand window, look for either "Log on locally" or "Allow Logon Locally" (it differs depending on which version of Windows you are using). Double click on the policy and add/remove users from that list accordingly and check the box next to "Define these policy settings:" to define who will be allowed to logon locally. By default, the following accounts/groups can logon locally to domain controllers:
- Account Operators
- Backup Operators
- Print Operators
- Server Operators
- Corresponding Internet Users (IUSR_)
As always, rather than directly editing the Default Domain Controllers Group Policy, you should create a new group policy object with the settings you want. Also, be advised that changing the default settings can cause unexpected and potentially damaging results to your systems.
Q: If you have two domains on your network that are located at the same physical site and you want to implement an account policy that requires passwords of at least eight characters and should meet complexity requirements -- do you apply the account policy setting at the site? What account policies should you use?
A: You would need to apply the account policy separately on each domain. Even though the group policy MMC snap-ins will display the "Password Policy" branch for OU's and sites, you can only define the password policy at the domain level. This is because there can only be a single password policy in a given Active Directory, which effectively means that you can only define it at the domain level. Also, just as a note regarding best practices, rather than modifying the default domain policy, you should go ahead and create an additional group policy object with the password policy settings that you want to apply.
Q: I have an NTFS folder on Windows 2000 Advanced Server. I want to set rights to this folder so that users are not able delete files or folders, while at the same time they are able to save and make changes in that folder. How can I do this?
A: This can be done by editing the advanced security properties of the folder and files. To do this, right click on the folder in question and select "Properties." Select the Security tab and click "Advanced." Add or edit the appropriate users and specify the following permissions:
Traverse Folder/Execute Data
List Folder/Read Data
Read Extended Attributes
Create Files/Write Data
Create Folders/Append Data
Write Extended Attributes
You may or may not need all of the above permissions for your specific requirements. The key is to remember to NOT grant the "Delete Subfolders and Files" and "Delete" permissions.
Keep in mind that you may need to remove inheritance to allow you to make the necessary changes.
Wesley J. Noonan has been working in the computer industry for over 12 years specializing in Windows-based networks and network infrastructure security design and implementation. Ask him a Windows network security question.
View questions and answers from all our Windows security experts here.
This was first published in March 2006