Administering access control

  • Article

Applies To: Windows Server 2003 R2

Administering access control

You can govern access control in Active Directory Application Mode (ADAM) at the directory partition level by assigning users memberships to the role-based groups that are located on each partition. You can customize access control in ADAM on an object-by-object basis using the dsacls command-line tool. Other considerations for administering access control in ADAM include the assignment of permissions to Windows security principals and the best practice of avoiding the assignment of permissions to built-in security principals.

For more information about the dsacls command-line tool, see Dsacls.

Default ACLs

By default, ADAM provides access control list (ACL) settings on each directory partition. Also by default, all objects on a given partition inherit these default ACLs. To customize access control, you can:

  • Modify the default ACLs on the partition objects.

  • Set new ACLs on individual objects.

  • Change inheritance settings on individual objects.

For a table describing the default access that is provided to each of the default ADAM groups, see Understanding ADAM users and groups.

For information about viewing and setting object permissions, see View or set permissions on a directory object.

Note

In ADAM, it is possible for an ADAM administrator, or for a user with sufficient access to the Administrators group, to remove member accounts from the ADAM Administrators group, possibly leaving ADAM without any valid administrators. To recover from this scenario, the assigned ADAM administrator, as the owner of the Administrators group, can repopulate the ADAM Administrators group with the appropriate accounts.

Custom authorization mechanisms

Depending on your applications, you may have applications that use a custom authorization scheme. With a custom authorization scheme, ADAM still performs the task of authenticating users, but the directory-enabled application manages its own set of authorization information. Even with a custom authorization scheme in place, ADAM continues to enforce the ACLs on ADAM objects. Therefore, if your application implements its own authorization scheme, you may want to assign more relaxed permissions on all ADAM objects, so that the ADAM permissions do not interfere with your application's authorization scheme. If you do relax permissions in ADAM in this way, be sure to prevent clients from gaining access to ADAM through Lightweight Directory Access Protocol (LDAP), thus bypassing your custom authorization mechanisms.

Role-based authorization

With Windows Server 2003, one way that a directory-enabled application can control access to directory objects is through role-based authorization, which is an alternative to ACL-based access control. In this scenario, a directory-enabled application does not expose LDAP but instead controls all access to the directory data. ADAM is used simply as a data store. For more information about role-based authorization in Windows Server 2003, see the Microsoft MSDN Web site.

Note

Using ADAM as an authorization store requires that you import ms-azman.ldf into the ADAM schema. You can import ms-azman.ldf through the ADAM Setup Wizard during installation or by using the ldifde command-line tool. For more information, see Importing LDIF files during setup.

Windows security principals

By default, authenticated Windows security principals in ADAM can only read objects in the schema directory partition. To enable authenticated Windows security principals to read any other objects, you can assign permissions on objects to the well-known security ID (SID) authenticated user. You can assign Read permissions for an entire directory partition by making authenticated user a member of the Readers group on that directory partition. Or, you can assign Read permissions on an object-by-object basis, using dsacls.

Best practices for assigning permissions

Although it is possible to assign permissions on objects to built-in security principals, it is recommended as a best practice that you avoid doing so. Built-in security principals represent user groups that are defined by the security system. These built-in groups take the form BUILTIN\groupname. For example, the Builtin Administrators group (SID S-1-5-32-544) exists on every computer. If permission assignments for a particular object are made to the Builtin Administrators group, the intent of this assignment cannot always be determined. In other words, ADAM cannot always tell whether a security principal requesting access to an object belongs to the Builtin Administrators group for which a permission assignment is intended.

It is also possible to assign permissions on objects to well-known security principals. Well-known security principals represent special identities that are defined within the security system, including Everyone, Local System, Principal Self, Authenticated User, Creator Owner, and so on. It is generally considered acceptable to assign permissions on objects to any of the following well-known security principals:

  • Anonymous Logon (after considering the possible security effects)

  • Authenticated Users (S-1-5-11)

  • Network (S-1-5-2)

  • Interactive (S-1-5-4)

  • Creator Owner (S-1-3-0)

  • Self (S-1-5-10)

As a best practice, avoid assigning permissions on objects to the following well-known security principals:

  • Network Service (S-1-5-20)

  • Local Service (S-1-5-19)

  • Local System (S-1-5-18)

The assignment of permissions on objects to any other well-known security principal should be made on a case-by-case basis, after considering the needs of the application.