What Application and Service Developers Need to Know About Groups

When designing an application or service, you can use groups to delegate administration or control access to the application or service as a whole or some portion of it. For example, an application might want to control who has the right to perform various administrative operations. You can do this by creating ACEs that allow specified access rights to the appropriate groups. In general, it's better to have an ACE that allows access to a group than to have several ACEs that allow access to individual users or computers.

Applications should adhere to the following guidelines when using groups:

• Do not create dependencies on hard-coded groups, which can cause serious problems if the group, for example, is deleted or moved.
• If possible, use you the appropriate built-in group rather than creating a new group just for your application. Creating groups that have a limited use (that is, the groups only apply when running the application or accessing the service) unnecessarily adds the SIDs for the groups to the access tokens of the users who are members of those groups. This can slow logon performance for those users (access token is created at logon time) as well as access checks when accessing resources.
• If you do create your own groups:
  • Protect the group by setting ACEs that control who can add or remove members.
  • Use global groups if they are used for access control on Active Directory objects.
  • Use universal groups only if necessary (member information is required globally using global catalog; group can contain any user/group). If you do use universal groups, place global groups in the universal group and add/remove users from the global group. Avoid excess change to universal groups for replication efficiency.
• Do not control access by checking group membership to determine whether the current user belongs to the appropriate group. Instead, use an ACE and control access by having the system perform an access check.

If you need to control access to operations that do not fit within the predefined access rights for Active Directory objects (see ADS_RIGHTS_ENUM), you can use the extended rights feature of access control in Windows® 2000.

To use an extended right to control the right to perform an operation

1. Create an extended right that defines the type of access to the application or service. See Extended Rights.
2. Create an Active Directory object that represents the application, service, or resource.
3. Add object ACEs to the DACL in the object's security descriptor to allow or deny users or groups the extended right on that object. See Setting Access Rights on an Object.
4. When a user tries to perform the protected operation, your application or service uses the AccessCheckByTypeResultList function to determine whether the extended right is granted to the user. See Checking an Extended Right in an Object's ACL.
5. Based on the result of the access check on the object, your application or service can allow or deny the user access to the application or service.

A service application could also create a group whose members would be the various service instances. For instance, a service with instances installed on multiple computers throughout an enterprise might have a common log file that all service instances write to. The service installation program creates the log file and uses a DACL to allow access only to members of a group. The group members would be the user accounts under which the various service instances are running, or if the services run under the LocalSystem account, the members would be the computer accounts of the host servers.