Effective Access Control: 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 controls 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 Windows with a two-level group structure and a few tools. 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, and 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, usually a manager responsible for approving and 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 Advanced. Use the Add button to add an entry for the owner-to-be to the ACL. Then, in the Permissions entries list, select the Take Ownership check box.

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 Advanced and then the Owner tab. Then in the "Change owner to" list, the owner-to-be selects his user account and clicks OK.

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 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 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.

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.

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. The additional option of delegating group membership management to business owners is just that - an option to use if it fits your needs.