Effective Access Control for Win2K and NT

Use a two-level method to regulate access to resources

The most important question about security within a company's internal network is, Who has access to what? Many companies lack a consistent method for controlling access to certain files. Domains containing tens of thousands of files and directories can have tens of thousands of users. Some tools give you a huge report showing each file that a user can access, but readers often have difficulty sorting through such a report's details. Also, those reports typically highlight one server and don't include an entire network. The reports don't tell you whether various levels of access are appropriate for the users.

Windows 2000 and Windows NT control access at the file level. But for access control to be effective and verifiable, systems administrators need to manage access at higher levels, such as applications, databases, and departmental or workgroup file-share areas. You can effectively manage access control in Win2K and NT by primarily using shareware tools and a two-level group structure. This method creates a control system that is easy to maintain, verify, and teach to others. You can also implement the new control structure in parallel with your system's current access-control structure, then remove the current structure.

Information Resource Ownership
To use this two-level access-control method, you first need to identify the information resources under your administration. Information resources are groups of objects to which you control access in the same way. For example, an information resource might be a Microsoft Access-based application or a report repository. An information resource might exist across several servers or platforms. You need to identify which files and directories compose the resource. Every resource needs to have a business owner, who is usually a manager responsible for approving who has access to the resource. If possible, identify the business owner by role or position rather than by name so that you don't need to update resource group descriptions whenever someone in the business owner position changes jobs.

Decide how the business owner will supervise access. You might designate the business owner as the owner of the objects that make up the information resource, then directly delegate access control to the business owner. Or, you might delegate object ownership to a trusted staff member who will execute permissions at the business owner's direction. Transferring object ownership is a two-step process.

Step 1. You need to grant Take Ownership special permission to the object's owner-to-be. To grant permission, open Windows Explorer, then open Properties for the object file or directory, select the Security tab, and click Permissions. Use the Add button to add an entry for the owner-to-be to the ACL. Then, in the Type of Access list, select Special Access and select the Take Ownership check box. In Win2K, the steps are similar, but you need to click Advanced after you add an entry for the owner-to-be.

Step 2. To take object ownership, the owner-to-be opens Windows Explorer, selects the object, opens Properties for the object, and selects the Security tab. The owner-to-be clicks Ownership, then clicks Take Ownership. In Win2K, the owner-to-be opens Properties for the object, selects the Security tab, and clicks Advanced. Then, the owner-to-be selects the Owner tab, selects an account in the Change owner to list, and clicks Apply.

Usually, you retain direct control of the objects and arrange to involve the business owner in access control to some degree. For example, you might arrange to use email to forward all access requests to the business owner for prior approval. Alternatively, you might immediately process access requests and inform the business owner later. For higher-security resources, you might also arrange to supply the business owner with regular reports listing users who have access to the resources.

You also need to determine how many levels of access a resource needs. For example, a report repository will probably need two levels: read access for people who view the reports and change access for the person or process that updates the reports. Table 1 shows the information that you need to initially collect for a hypothetical information resource: a sales-order report repository, in which the systems administrator is object owner. If you set up an access-control procedure in which an object owner who isn't the systems administrator manages the resource, you'll need to collect information about the object owner too. You don't need to store the information in a document because this two-level access-control method is self-documenting and automatically maintains the information.

Local and Global Groups
The two-level access-control method requires you to create one local group for each relevant access level for each resource. However, don't populate these resource groups with users. You'll also need to create global groups that you'll place inside the resource groups; these global groups will contain users. For example, Acme has sales offices in Detroit, New Orleans, and New York. Tom and Jerry are the Detroit sales representatives, Jekyll and Hyde are the New Orleans representatives, and Bonnie and Clyde are the New York representatives. Each sales office has a directory, SalesWorkArea, that shares local office files on that location's file server. Each local sales office needs change access to the directory on its server. Figure 1 illustrates the system layout.

To implement access control, create two groups for each location. First, create a resource group and name it after the resource and the access level you've given that resource. In NT 4.0, resource groups are always local groups that you create in a location server's SAM because only local groups can contain other groups. In this example, you'll name the resource group SalesWorkArea-Change. To open the group's description field, double-click the group in User Manager. Identify the business owner, the business owner's involvement level, and any other information describing the group or resource. In this case, the group's description might read: "Owner Mgr Sales; handled by admin with monthly report to owner." Grant this group change access to the SalesWorkArea directory. Second, create user groups for the different types of users who need access to the resource. In NT 4.0, you must use global groups to hold your users because only global groups can nest inside of local groups. In this example, create one global group for each branch, and name each group after the branch location and the department the group represents (i.e., DET-SalesReps, NO-SalesReps, or NY-Sales-Reps). Then, populate the global groups with the respective sales representatives at each location. Finally, place the global groups into the local groups. This gives each sales representative change access to the appropriate work areas.

This two-level access-control method is self-documenting and easily verifiable and lets you use groups to manage access. To check group membership and determine which resources a user can access, open User Manager, double-click the user, and click Groups. The resulting Group Memberships dialog box shows the user's group memberships. For example, Clyde is a member of the global group NY-SalesReps. To determine which resources Clyde can access, determine the local groups that NY-SalesReps is a member of on each member server. Clyde, as a member of NY-SalesReps, has change access to the SalesWorkArea directory on the New York server. You can document Clyde's access by looking at Group Memberships. You can also easily determine who has change access to an information resource such as SalesWorkArea. To determine that access, check SalesWorkArea's ACL. The ACL contains one entry that grants change access to SalesWorkArea-Change, which contains the SalesReps global group. Thus, sales representatives who populate SalesReps have change access to SalesWorkArea.

Adding Resources
The two-level access-control method also makes it easy for you to manage access when resources join the system. For example, Acme's corporate headquarters builds a central sales performance Access database (i.e., SalesPerf). All sales representatives need to have read access to the database, and all sales managers need to have change access. You need to create two local groups on the server on which the SalesPerf directory resides. Those groups, SalesPerf-Change and SalesPerf-Read, will have change and read access, respectively. To give sales representatives read access, simply add each branch office's SalesReps global group to the SalesPerf-Read local group. Then, create a global group for SalesManagers, add users to the group, and add the group to SalesPerf-Change. Figure 1 illustrates various user groups' access to SalesPerf.

This access-control method is self-documenting from either end point. You don't need to maintain a separate access-control database that will be constantly out of sync with current permissions and group memberships. Instead, group memberships and their descriptions document all access. In security, you need to be able to map system settings back to the underlying business rules that govern how access works. Group names and memberships reflect those business rules. You can control and verify user access entirely through group memberships instead of through troublesome file permissions. For example, if you were to simply grant the SalesReps group change access to the SalesWorkArea (and thus avoid creating the SalesWorkArea-Change group), the arrangement would properly express the business rule (i.e., sales representatives have change access to the sales work area directories). However, the business rule would exist deep in the object permissions instead of in the more visible group membership.

This access-control method makes verifying whether access control permissions are appropriate easy for systems administrators and auditors. The ACL for each resource-specific local group contains only one or two entries in addition to an entry granting the administrator full control. These entries are easy to verify; simply compare the group's name to the entry's permission level. For example, the SalesWorkArea-Change group should obviously have change access to SalesWorkArea. You can also verify each local group's membership. For example, you can easily verify that members of SalesReps in all the branch locations are SalesPerf-Read members.

When someone changes jobs, the two-level method lets you easily change the employee's access. For example, if Jerry moves from Acme's sales department to the marketing department, he automatically loses all access that he had as a sales representative when the domain administrator removes him from the DET-SalesReps group.

Drawbacks in NT
The two-level access-control method has some drawbacks when you use it in NT. The method uses more groups than you might be accustomed to. To get a complete picture of all resources that a user has access to, you need to rely not only on domain global groups but also on member servers' local groups. You need to determine which global groups the user is a member of, then look in each member server's SAM to see whether those global groups are members of resource-specific local groups. You can view a member server's local SAM from your workstation after you log on as a member of Domain Admins. To view a local SAM, open User Manager, click the User menu, then click Select Domain. Instead of selecting a domain in the dialog box that appears, enter the member server's name preceded by two backslashes, then click OK.

A better way to track local group memberships on member servers is to maintain a database that lists the memberships. Unless you have a sophisticated reporting tool such as BindView Development's Enterprise Management System (EMS), you need to use a tool such as SomarSoft's DumpSec to write a nightly batch file that extracts each server's groups and members. (For information about EMS, see Tim Daniels, "BindView EMS/NOSadmin," May 1997. DumpSec is available as a free download at http://www.somarsoft.com/.) DumpSec produces comma-delimited text files of every aspect of a server's security, including groups. You can import these files into a master database. If you also import your domain's global group memberships, you can query the database to determine every resource a user has access to.

Improvements in Win2K
The difficulty of looking in member servers' local groups for membership and access information disappears in Win2K because the OS lets global groups contain other global groups as members. This arrangement lets you use Active Directory (AD) to control all access within your domain groups. (This feature is available only in Win2K domains running in native mode. In mixed mode, domain group nesting is subject to the same limitations as in NT. Mixed mode is a Win2K feature that facilitates gradual upgrades of NT domain controllers to Win2K.) By placing your global groups in appropriate organizational units (OUs), you can delegate group maintenance to the appropriate administrators and conduct queries to monitor access throughout the enterprise. You can document a resource group's business owner by using the Managed By tab of the group object in AD, which Figure 2 shows. To reach the Managed By tab, open the Microsoft Management Console (MMC) Active Directory for Users and Computers snap-in, double-click the group whose owner you want to document, and select the Managed By tab. After you've implemented nested global groups, you'll need to look at directory and file permissions only when you create a new resource or perform an audit to check whether the group structure responds to the file permissions. Most information resources on a file server consist of one or more root directories, and when you audit the group structure, you need to make sure that the permissions are the same on each file and subdirectory. DumpSec provides an excellent permission report that highlights only the files and subdirectories in which the permissions differ from the parent's permissions.

The two-level access-control method is the best way I've found to determine who has access to resources in your system. The method fulfills the crucial requirements of any access-control method: It involves resource owners in access-control decisions, and it's easy to maintain, self-documenting, and verifiable.