The following excerpt is from Chapter 2 of the free eBook "Administrator shortcut guide to Active Directory security" written by Derek Melber and Dave Kearns and available at Realtimepublishers.com. Click for the complete book excerpt series.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Directory administration for Windows AD spans well beyond the AD database. With AD, security needs to be considered for all aspects of object management, GPO management, DNS management and general domain controller management.
If you are coming from a Windows NT background, AD management might seem foreign, as the management of objects, policies, DNS and domain controllers could not be segregated in NT. With NT, the objects were only controlled at the domain level; not at any level below the domain. This setup did not allow for delegation of administration to any objects in the domain. There were groups, such as the Account Operators and Server Operators, which allowed for some users to have control over a subset of objects in the domain. However, these groups did not allow for control over a subset of these objects, just the set of these objects as defined by the domain.
This mindset is dramatically changed with AD. In AD, delegation of administration allows for the domain administrators to delegate tasks to junior-level administrators and power users within a department. The same options are available for Account Operators and Server Operators as were available in NT, but with AD, these groups are not a suggested means to give delegated privileges. Instead, delegation of administration is provided at the OU level (it is also provided at the domain level, but the OU level is most common). This delegation is accomplished by configuring the ACL on an OU. As there are almost 1,000 permissions associated with a single OU, these permissions allow granular control over which task and function the domain administrator will delegate to the user.
As you can imagine, the options of what can be delegated are almost endless. Thus, delegation of administration must be designed into the AD security and implementation early on. As we will explore, the security related to delegation depends on the OU design and object placement in those OUs. If the AD implementation is allowed to progress without considering the security related to delegation of administration, the process to rearrange the objects to support a desired delegation model becomes very difficult. There are general guidelines that you need to keep in mind as you consider the security of the directory administration:
- The rules that applied to NT usually don't apply to Win2K and WS2K3 AD. This idea is difficult for many companies and administrators to get past. Much of the failure to consider this reasoning is that the NT methods have been in place for years and seem to work well.
- The AD security design needs to take full advantage of the power of AD. It is a shame to have companies spend so much time, effort, and money moving from NT to Win2K and WS2K3 AD to then not take advantage of the power that AD provides. The power of AD is in the ability to reduce the number of domains, which in turn, reduces the number of domain controllers, administrators and trusts (administrative overhead) and increases the ability to centrally administer the environment.
- The group design is essential for optimizing the security configuration of the directory. In some OSs, it is common to have built-in groups that provide widespread power over accounts, servers and services. With AD, these groups can still be used, but it is better to also use other groups that will be delegated administrative control over specific aspects of AD. The reason this design is better is that the built-in groups many times have control over all user accounts or all servers. With the delegation model, groups have control over a subset of the user or computer accounts. In addition to the limitation of object scope, the delegated group usually has a limitation set on the capabilities over those objects as well.
As the security of AD is designed, it will be important to logically organize the administration model. These models are typically implemented through the OU design. There are numerous designs and considerations. The following list highlights common methods for breaking down the administration model in AD:
- Regional -- It is common to have administration at the regional level (for example, West, East, Europe, Australia). Doing so provides administrators with the ability to control a larger group of accounts.
- Departmental -- Like most companies, administration might be broken down into departments such as Human Resources, IT, Accounting and Sales.
- Object function -- Administration of the directory might also be broken down by object function. It makes sense that the administrator of the HR user accounts is not in charge of the Financial servers. Typical object categories include user accounts, employee computer accounts, IT user accounts, servers, domain controllers and service accounts.
A poor decision that many administrators make is to duplicate the organizational chart for the company in an attempt to create the structure for security of the directory. Unfortunately, the organizational chart is not an effective AD security model because administration crosses too many boundaries that the organizational chart creates. This causes additional overhead in configuring and managing the directory security.
Click for the next excerpt in this series: Create usable boundaries.