Designing a Group Creation Strategy

As you are deciding upon the policies that you will implement for naming conventions and delegation of authority, you will also need to determine the strategy you will employ for resource access. You will need to create a guideline for group membership and nesting that will meet the requirements of your organization. You will start by identifying which resources the users will need to access, the level of access they will require, and then the strategy that you will implement to allow that access.

Identifying Resource Access Needs

Resources exist for a reason. Printers, folders, files, databases, e-mail, and many other resources exist within the network, and users will need to have access to those resources in order to perform their job functions.

You will need to determine the resources that exist within the organization. Even in small organizations, this can be a time consuming task, let alone what you will run into in a large organization. This is not a task that you will be able to perform on your own. Assign other users to documenting the resources that they are responsible for and which users need to have access to them. Once you have identified all of the resources on the network, you can look at the users who need to access them.

Look for users who need the same type of access to resources. These users will become the members of a group who have the same requirements. Try to keep the number of these groups to a minimum, but make sure that you do not allow user accounts to become members of groups where they do not belong.

Think of employees that have basically the same functions, such as accounting employees. There will be files that all of the accounting employees need access to, so you can include all of them into one group. You will also have resources that only a subset of employees , such as Accounts Payable, need to access. In this case you could add only the Accounts Payable staff members to the group.

Determining the Level of Access Required

The next thing you should do is review the access requirements for users. When determining the type of access different users need to the same resource, you should keep documentation for each level of permission. Once you have determined the level of permission required for each different type of user, you can create a security group for each of the access requirements. Add those security groups to the DACL of the resource and apply the appropriate permissions.

For example, a graphics design company may have a folder called PromoArt that contains sample artwork that they present to prospective clients. Members of the sales team need to be able to show the clients the artwork. Members of the Design team need to be able to modify their own artwork, but not any of the other artists work. The Art department managers need to be able to add and remove artwork from these folders as they determine which designs are going to be used for promotional purposes. Members of the IT department are responsible for maintaining the server that the design folder is on. They will need to have access to the directory so that they can back it up and restore it if necessary. They will also need to manage the permissions for those accounts that need to have access to the designs.

Domain Local groups could be created that allow for all of the specific permissions that the accounts will need. Because the Sales team needs Read permission, a group DL_PromoArt_Read is created. The Design team members and the Art department managers need to modify the artwork, so a Domain Local group named DL_PromoArt_Mod is created. Finally, because the IT group maintains the folder, a group named DL_PromoArt_FC is created.

Designing for Efficient Nesting

When using Windows XP Professional as the client operating system within your domain, you can allow a user to be a member of about 120 groups without having to change registry entries to allow more. However, the more groups that a user is a member of, the longer it takes for the user to log on to their system because the access token generation will take so long. Try to keep the group membership of a client to a minimum so that you will not incur long logon times.

You should try to use group nesting to your advantage. A well-thought-out design will allow you to streamline your administrative overhead. You should try to design so that you are nesting groups based on the most- restrictive /most-inclusive strategy . By using the most-restrictive/ most-inclusive strategy, you create groups that will include the fewest number of users where you want to control the membership, and then you add that group to other groups that allow less restrictive access to other resources. Take for instance a department where the management team has access to all of the resources that the employees of the department has. You could add the management team into a Global group and then add that Global group into another Global group that contains the department s employees.

For instance, you may have an Accounting division that includes an Accounts Payable and an Accounts Receivables department. There may be resources that the entire Accounting division needs to access. You ll also have resources that only the individual departments will need access to. You can create a group for the Accounting division managers and call it G_AcctManagers. The Accounts Receivables and Accounts Payables staff could be added to the groups G_AcctRec and G_AcctPay, respectively. You could create another group that would include all of the Accounting division staff so that they could access common resources, called U_AcctAll.

If the domain is at least at the Windows 2000 Native mode functional level, you could nest the groups to make administration easy. The G_AcctPay and G_AcctRec groups could be added to the membership of U_AcctAll. Now any new member of either G_AcctPay or G_AcctRec will have access to the resources that U_AcctAll has. Then, by adding the G_AcctManagers group to the membership of G_AcctPay and G_AcctRec, the members of G_AcctManagers would have access to the resources from all three groups. Figure 7.6 shows a representation of this strategy.

Figure 7.6: Nesting groups for efficient resource access

If a new Accounts Receivables employee is hired, their account can be created and added to the G_AcctRec group. Once added, the new user will have access to all of the resources provided to members of the G_AcctRec group and the U_AcctAll group. If a new manager was hired for the Accounting division, the user account for the manager could be added to the G_AcctManagers group. Assuming this was the case, the new manager would have access to all of the resources from all of the following groups: G_AcctManagers, G_AcctPay, G_AcctRec, and U_AcctAll.

If you can follow this strategy for all of the groups within your organization, you should be able to add and remove most user accounts with very little trouble. You ll have to plan more as you study the combinations of groups and evaluate the best nesting procedure, but the longterm administration will be much easier.