Protect Your Windows Network: From Perimeter to Data

Access control is a layered process. Think of it as a funnel, where you have to be able to pass through the smallest tightest part of the funnel to get through. Suppose you want to do something with an objecta file, a Registry key, a directory element, whateveron a network resource. Your authorization to access that object passes through a series of access control checks; if your authorization fails at any point, you do not get access. Let us examine the layering present in file access controls:

1. Can you access the resource over the network?

   This is controlled through the logon right "Access this computer from network" (SeNetworkLogonRight) in security policy. If you want to get to some object on a network resource, you need this right. And, hopefully, you do not also have the "Deny access to this computer from network" because that right supersedes the former.

2. Can you map a drive letter?

   This is controlled through share-level permissions and can be one of three types: read, change, or full control.

3. Can you get to the folder containing the file?

   The file might live deep within some folder structure with tightly controlled access throughout. Although you might not have access to any of the parent folders, you do need at least to pass through, or traverse, them. This is controlled through the privilege "Bypass traverse checking" (SeChangeNotifyPrivilege). By default, Everyone has this right, so it is probably not something you need to worry about.

4. Do you have access to the folder containing the file?

   You will need access to the folder containing the file you are after, and this is controlled by permissions on the folder.

5. Finally, do you have access to the file itself?

   You will need the correct permission on the file to do whatever your task requiresexecute, read, write, append, delete, or others.

Besides the file system, you can assign permissions to other objects, such as Registry keys, services, printers, Terminal Server connections, WMI objects, and Active Directory objects. Just about anything in Windows that can be considered an object can have an ACL.

On services, you can assign permissions that govern who can modify the service, start it, read its configuration, and so on. In addition to the ability to read the service configuration and start the service, the service account also needs the "Log on as a service" (SeServiceLogonRight) right. As we discussed in Chapter 14, "Protecting Services and Server Applications," also make sure that you either configure the service account so that the password never expires or remember to change the password before the expiration dateotherwise, the service will not start. And speaking of service accounts, here is another good reason for eliminating account lockouts from your security policies. A simple denial-of-service attack against an IIS server is to lock out its IUSR and IWAM accounts, which is trivial for an attacker who knows the name of your Web server.

Terminal Services security can be configured either on the whole computer or on individual connections. Default computer-wide control grants the Remote Desktop Users group the RemoteInteractiveLogon right. For more fine-grained controlsay you want to prevent users from ending sessionsyou can modify individual user and group permissions on the Properties tab of the connections in the Terminal Server UI.