The following excerpt is from Chapter 2 of the free eBook "Administrator shortcut guide to Active Directory security"...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
written by Derek Melber and Dave Kearns and available from a link at Realtimepublishers.com. Click for the complete book excerpt series.
Delegation of administration
Delegation is one of the key security reasons to move from NT to Win2K or WS2K3 AD. The benefits that delegation provides are superior to any directory control mechanism that is available in NT. A chronic complaint about NT is that it does not provide any granular administration capabilities within the directory. The most granular administration possibilities are offered through Account Operators, Server Operators, Print Operators, and Backup Operators -- groups that are built-in to the OS. There is the capability of creating additional groups within the directory and configuring special user rights for them. However, this feature only provides marginal improvements over the built-in groups, because the user rights do not allow control over a portion of the environment, only tasks within the environment.
AD delegation of administration provides granular control over objects within the directory. The following list highlights examples of common delegated tasks:
- Create user accounts -- Provides the assigned delegate the ability to create user accounts. However, the delegate could not manage or delete the user accounts after the accounts are created. If this delegation were assigned at an OU, the delegate could only create user accounts in the specified OU.
- Delete user accounts -- Provides the assigned delegate the ability to delete user accounts. The same rules apply as for the creation of user accounts in that the deletion of user accounts is the only task the delegate can perform, and the scope could be limited if applied to an OU.
- Manage user accounts -- Management of user accounts is a common task. However, with delegation, the management scope can be limited to an OU, which include only a subset of user accounts in the domain.
- Reset passwords on user accounts -- This task is one of the most prevalent help desk call requests and can be delegated to the help desk staff, management in a department or a power user over a subset of users in the domain.
- Read all user information -- Auditors, management and security professionals need to have access to all account information to complete their jobs. However, this task of reading information is not for everyone, nor is it for these groups all of the time. With delegation capabilities, this task can be easily added and removed.
- Create, delete, manage groups -- These tasks follow the same logic as the user accounts. They can be grouped together to give the delegate all three tasks or separated to provide the delegate with a narrower set of tasks for the groups in the domain.
- Modify the membership of a group -- One of the specialized tasks included in managing a group is to add or remove members of that group. This is a good example of the granularity that can be accomplished with delegation of administration.
- Manage Group Policy links -- GPOs have powerful results; thus, it is ideal to separate the roles of GPO management. AD delegation of administration enables an administrator to allocate one or many of the roles related to GPOs.
There many more capabilities of delegation of administration within AD to provide granular security control to any object. With all of this complexity, you can quickly see that planning will be crucial to a successful implementation of AD security with delegation. As we have already discussed, planning should not be bypassed. The testing phase will provide a time to verify that all security measures are upheld when the delegation of administration is implemented.
The design of delegation is, for the most part, integrated into the OU design. The reason for this integration is that delegation at the domain or site level has too broad of a stroke. Every user and computer account is included when delegation is performed at the domain level. The site delegation model has a similar problem, in that it encompasses too many objects to be a viable security solution. As OUs are the core to the logical structure of AD and to delegation of administration, great time and effort needs to be given to them during the planning and testing phases.
Certain tasks can even be delegated to non-IT personnel. For many, this concept is foreign and difficult to comprehend. However, after further consideration, you will find that it can improve efficiency, security, scalability and ROI:
- Improved efficiency -- Delegating administration to non-IT personnel can improve the efficiency of your IT staff. Instead of end users always calling the IT staff to get a common task accomplished, the users can call a coworker or manager to get the problem fixed.
- Security -- When too many IT staff members have access to resources and AD objects, there can be vulnerabilities of rogue administrators and too many administrators. With delegation to non-IT staff, the burden can rest on the owner of the resource in many cases, by allowing control over groups and the resource itself to the owner of the resource.
- Scalability -- AD by itself is very scalable. When the administration of common tasks is delegated to non-IT staff, the opportunity of growing the IT infrastructure without growing the IT staff becomes very possible.
- ROI -- The ROI for installing AD and newer OSs on servers and client computers is very high as a result of delegation of administration. It is only with Win2K and later that users can be delegated administrative privileges because earlier OSs either can't function in a domain or have problems performing administrative tasks in AD.
Click for the next excerpt in this series: Two kinds of administrators.
Click for the book excerpt series or visit Realtimepublishers.com to obtain the complete book.