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

Best Practices for Delegating Control in AD

You might be tired of me hounding you on the phases of planning and testing, but I can’t stress enough how important these two phases are in the stability, security, and long-term effectiveness of your AD deployment. Thus, the initial best practice for AD delegation of control is planning and testing. The next best practice is to use the power of AD as much as possible by employing OUs for delegation, non built-in groups for delegation, and nested OUs for the optimum design of your delegation.

• OUs for delegation—OUs must be designed and implemented properly and the correct objects (user, group, computer) must be placed in them in order for delegation to be successful.
• Use of non built-in groups—Built-in groups give too wide of privilege in the domain, so the delegation design must include the creation and location of new groups designed solely for delegation.
• Use of special administrative accounts—For best security and autonomy of data administrators’ and service administrators’ tasks, it is ideal to create user accounts for when the user performs these tasks.
• Use of nested OUs—There will be various levels of data administrators within AD. Some will be delegated control over an entire data type, such as servers, and others might only be given a subset of the data type, such as file servers. This hierarchy is established by creating OUs and sub-OUs, with the delegated administration at the top having more privilege than those lower in the OU structure.

There are additional best practices and tips that have been successful for many organizations that use delegation of administration to control security of AD. One best practice while delegating administration is to not provide too much delegation. For example, suppose you are delegating administration to a user in the Sales department. You are giving the user the ability to control membership in the groups for the Sales department. The OU structure related to Sales might look something like

     Sales 
          Computers 
          Groups 
          Users

An easy solution for delegating the administration would be to create a new group in the Groups OU named Sales_Groups_Admins. You would then add the appropriate users from the Users OU to the Sales_Groups_Admins group. The final step would be to delegate at the Groups OU administrative control to change group membership to the Sales_Groups_Admins group.

Although this process would accomplish the goal, it also provides too wide of privilege for the members in the Sales_Groups_Admins group. As the Sales_Groups_Admins group is located in the Groups OU, all of the members of the Sales_Groups_Admins group can add or remove members to this group too. Thus, they could add employees to the group that should not have the privilege to modify group membership for the other groups in the OU.

A solution to this potential vulnerability is to create an Administrative OU at each level where delegation is performed. For example, the OU structure would now look like

     Sales 
          Administrative 
          Computers 
          Groups 
          Users

You would still create the users in the Users OU, but you would not create the Sales_Groups_Admins group in the Groups OU. Instead, you would create this group in the Administrative OU. Then when you delegate administration for this group to control the group membership for groups in the Groups OU, it will not include the Sales_Groups_Admins group.

Another best practice when working with delegation is to perform regular audits on who has been given delegated administrative privilege to different levels in AD. There are two methods to audit this activity. If your company has the manpower and stamina to audit as the activity occurs, you will need to use the built-in auditing that is provided for the OS. If your company is running low on manpower and the IT staff already has too many things to do, it might be best to perform manual audits on the delegation in AD. This can be performed by first documenting where any delegation is configured. If documentation is available, tools such as dsacls.exe and acldiag.exe can acquire the delegation configurations at each level in AD. Then a quick comparison of the actual settings versus the documented settings can be performed.

Any delegation that performed at the domain level can typically be accomplished by using the built-in groups for domain administration. These groups include Domain Admins, DNSAdmins, DHCP Admins, RAS and IAS Servers.

Delegation control over sites and site replication is typically controlled at the forest level because site management is a forest-level function. You typically would not attempt to delegate specific site responsibilities because the service administrators responsible for site management would need to control all sites as a whole, not independently. Membership in the Enterprise Admins group would provide the typical site administration roles and responsibilities. If granular control over sites is needed, there are specific tasks that can be delegated.

Directory Tools

There are numerous directory tools that are available in a default installation of AD. These tools are essential to the core function, management, and troubleshooting of AD and its related services. There are also resource kit tools that help increase the management capabilities of the directory. As far as security-based tools, almost every tool can be tied back to security in some manner. Security is in almost every aspect of AD and the tools that manage it—from the files that run the directory to the accounts that reside in the directory to the sites that replicate the directory between domain controllers. Tables 2.1 provides the most common built-in, command- line, and resource kit tools.

Tool	Use	Security control
Built-In Tools
Active Directory Users and Computers	Used by data administrators to manage all security principals, GPOs, contacts, AD shares, AD printers, and OUs	User accounts, group accounts, delegation administration, GPO management
Active Directory Domains and Trusts	Used by service administrators to create and manage trusts to external domains	Trusts that go outside of the forest
Active Directory Sites and Services	Used by service administrators to create and manage sites and replication	Controls replication schedule between sites and subnets associated with sites
Computer Management	Controls “computer” aspects such as hard drives, services, and the local Security Accounts Manager (SAM)	Local SAM (non-domain controller), services, shared folders, drivers
DNS	Manage DNS	Secure dynamic updates, replication partners, manual DNS entries
Event Viewer	View tracked events for the system, applications, and security	View security logs
Routing and Remote Access	Manage routing and remote access services	Specify RAS protocols and security; determine RAS access for users
Command-Line Tools
Adprep	Prepares your existing Win2K AD for WS2K3	Changes the schema to prepare for WS2K3
Ds* tools	Provides access to AD for creating, querying, deleting, and moving objects within the directory	Provides means for someone to access AD remotely from the command line
Shutdown	Allows the shutdown of a server remotely	Can shutdown a server or domain controller remotely from the command line
Bootcfg	Displays and modifies contents of the boot.ini file	Can change the main boot file of a server or domain controller remotely from a command line
Resource Kit Tools
Dumpfsmos	Dumps Flexible Single Master Operations (FSMO) roles from AD	Provides location of all FSMO roles on each domain controller
EventCombMT	Gathers Event Viewer logs from the network computers and organizes them to files in a single folder	Access to security logs remotely
Lockoutstatus (Server 2003)	Dumps the lock out status of user accounts	Access to which accounts are locked out
Ntrights	Sets user rights on servers and domain controllers	Allows for remote user to set user rights from command line
Showacls	Displays the ACL for resources	Access to the ACL to see which users and groups have access

Table 2.1: Built-in, command-line, and resource kit tools for AD with the security controls that the tool provides.

For AD administration, the main tools are those that are built-in and provide a user-friendly graphical interface. These tools are designed to use the Microsoft Management Console. MMC allows for customization beyond the default Administrative Tools that are pre-built and available from the Start menu.

When an organization becomes too large or delegates administration to many different aspects of the AD structure, it becomes a necessity to build custom MMC consoles. Such consoles are easy to create and can be specific in what they show. When an MMC is customized, it is done so by importing snap-ins, which are the administrative tools themselves. There is a snap-in for almost any administrative task for the directory. The following list highlights common MMC snap-ins that are used to control AD and the security of AD:

• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Active Directory Users and Computers
• Active Directory Schema
• Active Directory Service Interfaces (ADSI) Edit
• Computer Management
• Dfs
• DNS
• Event Viewer
• Group Policy
• IP Security Policy Management
• Shared Folders
• System Information

Figure 2.1 shows the MMC and a list of snap-ins.


Figure 2.1: MMC with a list of snap-ins.

The benefit of the MMC is that the essential snap-ins can be grouped in a single interface, then saved in the MMC. After it is saved, it can be shared on a central server or sent via email to an administrator that has been delegated administrative access to resources within the snap-in.

For most organizations that use this method, the administrator or non-IT employee will need to have the tools that administer domain controllers, servers, and AD installed. This installation is easily accomplished, as the suite of tools is available on all domain controllers. The file that contains the suite of tools is called adminpak.msi. This installation package can be shared on a central server for installation across the network, sent via email to the administrator, or pushed out through a GPO. After the installation package is installed, the user will have the full list of administrative tools necessary to complete the delegated administrative task.

For some administrators, especially those that are non-IT employees, the full-blown administrative tool that comes with the adminpak.msi can be too much. Thus, instead of teaching and encouraging these administrators to use the tools, you can create Taskpads that narrow the scope of what they see in the interface. Taskpads are created within each snap-in and can be very specific with their focus.

An example of a Taskpad is providing delegated administrators the ability to see only user accounts and giving them the option to only reset the accounts’ passwords. This option is useful for a non-IT employee that has been delegated the privilege to reset passwords for an OU full of user accounts. Typically, administrators must open Active Directory Users and Computers, then navigate to the correct OU. Once they arrive at the OU, they see all of the objects in the OU, including groups, computer accounts, other contacts, printers, shares, and other OUs. This view can be quite confusing. The Taskpad will show them a single view of the user accounts in the OU in which they have been delegated the ability to reset passwords. They will then have one option, which is to reset passwords for these user accounts. Figure 2.2 shows a Taskpad for resetting passwords for an OU.


Figure 2.2: An MMC Taskpad providing the delegated administrator the ability to reset passwords.

The use of Taskpads can save many calls to the Help desk or the administrative staff, as users who have not been educated in the finer points of the administrative tools can quickly access the tasks that they need to perform. These Taskpads can also be placed on a central server, emailed, or manually copied to provide access to all administrators.

These tools and features perform useful services for data administrators and service administrators, but they can be clumsy for large organizations and fall short when there are too many resources, objects, servers, or users. Many of the tools have built-in limitations to show only 10,000 AD objects. These limitations can be overcome, but when an organization has 20,000 users, 50,000 groups, and 25,000 computer accounts, the list of objects can take a very long time to refresh in these graphical tools. At this stage, it can become a task in itself to try and find the object that you are looking for.

In addition to the lack of scalability of these tools, there is another limitation. The MMC can’t import or support all of the features required to administer the domain and AD. Both data administrators and service administrators need a tool that can combine every feature that they might need to control, along with fully customizable interfaces. Such a tool would provide a one- stop shop for all of their needs, with the robust interface capable of supporting the customization required to make the job easy. There are many third-party tools available that provide such features. These solutions meet almost any need for data administrators and service administrators, including:

• AD migrations
• Active templates for easy delegation
• Auditing
• GPO administration and migration
• Cross-platform integration and management
• Built-in recovery for AD
• Advanced ADSI management
• Advanced AD querying

If your company is struggling to keep on top of AD security and management tasks, these tools can help centralize those tasks, making administration and delegation for everyone involved easier and more efficient.

















Your IP address will be sent with this e-mail

From e-mail to e-mail