Delegation of administration is a valuable tool for organizations to confine the security administration so that it applies only to defined subsets of the entire organization domain. The important requirement is to grant rights to a small set of users or groups to manage their area of responsibility, but not give them permissions to manage accounts in other parts of the organization.
Delegation of responsibility to create new users or groups is defined at the level of an Organizational Unit (OU), or container, where the accounts are created. Group administrators for one organizational unit will not necessarily have the ability to create and manage accounts for another organizational unit within a Domain. However, domain-wide policy settings and access rights defined at higher levels in the Directory tree can apply throughout the tree by using inheritance of access rights. There are three ways to define the delegation of administration responsibilities:
Delegate permissions to change properties on a particular container, such as the LocalDomainPolicies of the Domain object itself.
Delegate permissions to create and delete child objects of a specific type underneath an OU, such as Users, Groups, or Printers
Delegate permissions to update specific properties on child objects of a specific type underneath an OU, for example, the right to Set Password on User objects.
The Directory Service Administration user interface makes it easy to view the delegation information defined for containers. Adding new delegation of permissions is also easy to do by selecting who you want to delegate permission to and choosing what permissions they need.
Integrating the security account repository with the Windows NT Directory Service provides real benefits to manage the Enterprise. Performance, ease of administration, and scalability for large organizations are the direct result. Internet-based Enterprises can use Domain trees and hierarchical OUs to organize accounts for business partners, frequent customers, or suppliers with specific access rights to their system.
Large organizations typically depend on many individuals or groups to secure and manage the network account infrastructure. They need the ability to grant access rights for specific operations—such as resetting user passwords, or disabling accounts—to specific groups without also granting the permission to create new accounts or change other properties of user accounts.
The security architecture for Directory Service objects uses Windows NT security descriptors to control object access. Every object in the Directory has a unique security descriptor. The Access Control List (ACL) in the security descriptor is a list of entries that grant or deny specific access rights to individuals or groups. Access rights can be granted or denied with different levels of scope on the object and can be defined on any of the following levels:
Granting uniform read/write access to all properties of an object is the default access permissions for the creator of the object. Granting or denying object access permissions to a property set is a convenient way to define permissions for a group of related properties. The grouping of properties is defined by the property set attribute of a property in the schema. The property set relationship can be customized by changing the schema. Finally, the definition of access rights on a per-property level provides the highest level of granularity of permissions. Definition of per-property access is available on all objects in the Windows NT Directory Service.
Container objects in the directory also support fine grain access with respect to who has permissions to create child objects and what type of child objects they may create. For example, the access control defined on an Organizational Unit (OU) can define who is allowed to create User objects (accounts) in this container. Another entry in the access control for the OU might define who is allowed to create Printer objects. Fine grain access control on directory containers is an effective way to maintain organization of the directory name space.
A new implementation of the "ACL Editor," the common dialog control for viewing or changing object security permissions, provides an easy-to-use interface for defining access rights to Directory Service objects by property set or individual properties. The ACL Editor also supports defining "inherited" access rights on container objects that flow down to all sub-objects in that portion of the directory tree.
The Windows NT next generation Directory Service provides intuitive and powerful administration tools. Objects can be hierarchically organized so that they can model large organizations. And the graphical user interface delivers one of the most requested administrative tools—a drag-and-drop control console. This console has a graphical user interface that provides an object-view of administration. For example, to do pruning and grafting, the administrator would grab the top of the merge-from tree and then drag and drop it onto the target domain. A dialog box asks the administrator to confirm the action. Of course, the administrator must have rights in the merge-from tree to merge it with another tree, and in the merge-to domain to bring new trees into it.
Anything that can be done through a UI should be able to be done programmatically or from a script. To allow an administrator to write command procedures, the Windows NT next generation Directory Service provides full support for OLE automation and scripting. This makes it possible to add, change, move, copy, and perform other administrative functions by scripted manipulation using Active Directory, and a scripting language such as, Java, Microsoft® Visual Basic® Script, or others.