What Application and Service Developers Need to Know About
When developing an application or service, you can use groups to
delegate administration or control access to the application or
service as a whole or part. For example, an application can control
who can perform various administrative operations. To do this,
create ACEs that grant specified access rights to the appropriate
groups. It is good programming practice to have an ACE that grants
access to a group than to have several ACEs that grant access to
individual users or computers.
It is recommended that applications use the following guidelines
when using groups:
Do not create dependencies on hard-coded groups, which can
create complications if the group is deleted or moved.
Use 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
Use global groups if they are used for access control on Active
Use universal groups only if necessary (member data 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
If you need to control access to operations that do not fit
within the predefined access rights for Active Directory objects,
you can use the control access rights feature of access control in
Windows® 2000. For more information, see ADS_RIGHTS_ENUM.
To use a control
access right to control the right to perform an operation
Create a control access right that defines the type of access
to the application or service. For more information, see Control Access Rights.
Create an Active Directory object that represents the
application, service, or resource.
Add object ACEs to the DACL in the object security descriptor
to grant or deny users or groups the control access right on that
object. For more information, see Setting Access Rights on
When a user attempts to perform the protected operation, your
application or service uses the AccessCheckByTypeResultList
function to determine whether the control access right is granted
to the user. For more information, see Checking
a Control Access Right in an Object's ACL.
Based on the result of the access check on the object, your
application or service can grant 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 example, 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 grant 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