The Administrator Shortcut Guide to Active Directory Security Chapter 2

{LANG_NAVORIGIN} Operating System Microsoft
By: Derek Melber, Dave Kearns, and Beth Sheresh, 04/06/2005

Select the Proper Directory Structure

The directory structure will be one of the final decisions that come from the AD security and structure planning and testing. The directory structure for AD must go beyond the main directory and include DNS. DNS is an integral part of AD, so much so that AD can’t effectively function without DNS. There are many directory structure options, each having advantages that relate to security for the enterprise:

• Single AD domain—This structure is the ideal structure for any environment. If every security consideration, service, object, and application can function in a single domain, it should be the structure that is selected. This structure provides a single point of administration that is easier to secure than a multiple-domain environment. With a single domain, there are no trust relationships or cross-domain permissions to manage.
• Single tree forest—A single tree is simply multiple domains that share a domain suffix. With a single tree, all of the benefits of a single domain are lost. There will be a trust relationship between all domains in the tree. User accounts from each domain will be able to access resources in all other domains, if they are given permission to do so. There will be multiple Domain Admins groups—one for each domain. There will be multiple account policies that need to be designed and maintained. The GPO administrative overhead increases with each new domain that is considered in the structure, because each domain keeps track of its own GPOs.
• Multiple tree forest—A multiple tree forest structure is identical to a single tree forest with regard to security considerations. There are simply more domains and domain suffixes that need to be implemented.
• Empty root—An empty root structure is one in which the first domain (root domain) is designed so that it does not include any user or computer accounts. The other child domains under the root domain will contain all of the user and computer accounts. This setup is beneficial from a security perspective in that the Enterprise and Schema Admins groups are isolated from other users and administrators. With this design, a few administrators can be selected to control the Enterprise and Schema Admins groups, and all other administrators reside in the child domains, configured to be Domain Admins.
• Forest trust—New to WS2K3 is an option called the forest trust. The forest trust allows companies that have their own AD environment to “splice” their environments together. This splice does not share a schema, but it does allow all user and computer objects from one forest to access resources in the other forest. The forest trust has advanced hardware and OS requirements: All domain controllers need to be running WS2K3, and the domain and forest functional levels need to be increased to WS2K3 levels.
• DNS—DNS is the service that AD uses to resolve computer names and AD services for client computers, servers, and domain controllers. AD will not function without DNS. Therefore, it is essential to consider DNS in the design of AD and the security of AD. Some of the DNS security considerations with respect to AD include:
  • AD integrated zones—When a DNS zone is integrated with AD, it stores the DNS database in the AD database. The benefits of this functionality include fault tolerance, management, and authentication of computers attempting to update DNS records.
  • Secure dynamic updates—DNS now supports dynamic updates, which allows the computer to communicate with DNS to exchange computer name and IP address information to update the DNS database. The problem with this solution is that almost anyone can "spoof" the computer name and IP address, which will redirect communications from the valid computer to the spoofed computer. If secure dynamic updates are configured, the spoofing computer must be validated by the AD domain before it can update any records in the DNS database.
  • DNS ACLs—When a computer securely updates its DNS records, the records become the owner of the entry. This setup further protects DNS and AD, such that only the registering computer can update that record from then on.

Delegate Administration Whenever Possible

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.

Your IP address will be sent with this e-mail

From e-mail to e-mail