Active Directory: Protect your Active Directory data
There are a number of tactics for ensuring only the right people have access to the right data within your Active Directory infrastructure.
Darren Mar-Elia
Adapted from “Protecting Critical Data by Managing the Active Directory Identity Lifecycle” (Realtime Publishers)
You must protect your Active Directory-based identity data. It’s an important part of ensuring any identity system you put in place that works with Active Directory is protected such that it’s able to do its job of authenticating and authorizing the right people to the right resources.
You have to ensure the data within Active Directory is sacrosanct and only users with a business reason to access Active Directory information are granted that access. All the great identity-provisioning processes in the world won’t help you if your Active Directory is a free-for-all that anyone can fiddle with to his heart’s content. You need to take a deep look at your Active Directory security model and determine the best techniques and best practices for securing the data residing within.
The challenges of securing Active Directory
Managing the Active Directory security model isn’t exactly straightforward. The nature of a hierarchical directory service that serves many purposes (including application directory, authentication directory, desktop management directory and so on) means the security model can be a handful. More important, if you don’t take a proactive approach to managing your Active Directory security, it can quickly get out of control.
Consider, for example, the simple task of delegating user account management in Active Directory. Because of the granular nature of the Active Directory security model, a seemingly simple task such as managing user accounts could evolve into a dizzying array of permissions you’ll have to delegate:
- Permission to create user objects
- Permission to delete user objects
- Permission to move user objects
- Permissions on user object properties (this may break down into sensitive properties, such as department, manager, and group memberships, and non-sensitive properties such as telephone number and office address)
- Permission to reset the user’s password or unlock his account
- Permission to control who can change a user’s permissions
This list is by no means comprehensive, but it underscores the potential complexity of managing delegation on just this one task. Consider that each of these tasks (or at least groups of them) might be delegated to other subgroups. These permission sets might also vary based on the organizational unit (OU) in which the users are located. Add to the mix that parent objects in Active Directory can inherit permissions from their children (for example, permissions can move from the Marketing OU to the Users OU under Marketing). You can see things can really get gummed up if you’re not careful.
Not only is the complexity of the Active Directory security model challenging, it requires discipline to establish a good delegation model and keep it organized over time. One-off requests and unusual business needs drive you to make compromises. The ultimate goal is to protect the data in Active Directory that’s critical to your organization’s authentication and authorization mechanisms, so it’s important to keep a handle on Active Directory security.
Understand the Active Directory security model
Understanding the Active Directory security model is about comprehending how Active Directory is structured. Not unlike a relational database, Active Directory contains a schema that defines the available classes of objects and their associated attributes. A user object in Active Directory is an instantiation of the schema class “user.” That user object, as per the schema, contains a set of attributes such as first name, last name, department, manager, phone number and so on.
Each object in Active Directory also has an associated security descriptor. This security descriptor defines the permissions on that object. These show an example of a user object’s permission set, or Access Control List (ACL), as viewed from Active Directory Users and Computers.
The ACL is composed of a set of security principals (usually users or groups) that have rights over that object, and the rights or permissions associated with each security principal. A particular permission can be either an “Allow” or “Deny.” Allow is the default. This grants a permission to the security principal. If Deny is selected, then that permission is explicitly denied to that security principal. In fact, if an object inherits permissions from its parent and there are clashing Allow and Deny Access Control Entries (ACEs) for a given permission, then typically the Deny will win.
Standard and extended rights
Not every object class in Active Directory has the same set of associated permissions. This is great because it means you can tailor permissions to the type of object involved. Consider this example: a “trigger replication” permission associated with an Active Directory naming context object lets you delegate who can force replication between two domain controllers. Trigger replication has no relevance to a user object, though. In fact, every object has an associated set of “standard rights.” These include familiar ones such as:
- Read
- Write
- List
- Create
- Delete
- Read and Write Properties
Beyond the standard rights, a schema class can also have extended rights. Familiar examples of extended rights are the permissions found on a computer object. A computer has permissions such as “Read and Write host name attributes” specific to the computer class of each object.
This extensibility within the Active Directory security model lets you create a rich and granular delegation of tasks for your administrators and users. If you extend the Active Directory schema with a new class of object, it can have its own set of extended rights that control delegation specific to that object type (though you also have to be aware of the various differences across the object classes you want to delegate).
Understand security inheritance
Another aspect that makes the Active Directory security model challenging is the notion of inheriting permissions through the Active Directory hierarchy. A permission set at the top of a domain can trickle all the way down through nested OUs to objects at the lowest levels of the domain hierarchy.
You can control this inheritance, both from the top down as well as the bottom up. For example, say you’re setting permissions for user objects within an OU hierarchy composed of a top-level Marketing OU and two sub-OUs called Users-East and Users-West. You want to take advantage of inheritance to set permissions for all user objects at the Marketing OU level and have that trickle down to all user objects in both sub-OUs. You can do so by creating the new ACE within the Marketing OU’s ACL (using Active Directory Users and Computers as an example) and then, after setting the permissions, have it apply to all “Descendant User Objects.”
If you were running the Users-East OU, you might decide the permissions placed upon your user objects at the higher level don’t apply. If you have sufficient permissions, you can essentially turn off the inheritance that comes down from the Marketing OU. You can do so by simply clearing the checkbox in the Advanced section of the ACL editor in Active Directory Users and Computers. That breaks that inheritance chain.
Understand delegation
Within the context of Active Directory, delegation is the process by which you grant permissions to Active Directory objects. This lets users and groups perform specific tasks against Active Directory objects. Delegation implies some kind of orderly plan for giving the right users the right permissions on the right Active Directory objects, across your Active Directory structure.
An example of delegation may be a group called Help Desk Admins, to which all help desk team members belong. You can grant this group the ability to reset user passwords on all user objects within your Active Directory domain. This lets them handle one of the primary tasks of their job. Another common example of delegation is letting admins join computers to the domain. This is a delegated permission on computer objects, typically applied to OUs where computer objects might reside.
Creating a delegation model for Active Directory is probably one of the most important planning tasks you can perform. This is especially true when it involves delegating access to sensitive data held within Active Directory. It doesn’t matter whether you’ve just rolled out Active Directory or if you’re in the process of migrating your 10-year-old Active Directory to a new domain structure. In either case, it’s never too late to plan and create a delegation model that protects critical objects within Active Directory and delegates access appropriately.
There’s a lot of data within Active Directory that can and should be secured, but not all of it relates to your identity system. The following list highlights areas to start with in terms of protecting your identity data within Active Directory:
User properties: Attributes on your users may or may not be sensitive and require delegation. There are certain attributes—such as the user’s Job Title, Department and Manager—that are often managed by the HR department. If Active Directory is integrated into an HR system, those attributes might be managed through that system. In that case, you’d want to prevent all users from being able to modify these attributes on their own.
Group memberships: You can use groups to control access to a variety of resources, from public file servers to sensitive database data. Controlling who has permissions to change group memberships is probably one of the first steps you should take in your Active Directory delegation tasks. This translates into who can write to the Members attribute on Active Directory group objects. A user with this permission can modify group memberships.
OU moves: Although moving objects such as users between OUs may seem fairly benign from an identity-management perspective, such a move can often have downstream effects. Some organizations have automated processes associated with OU membership that could change things, such as a user’s group memberships or what Group Policy settings they process. These changes could inadvertently grant the user unintended access to resources. As a result, moving OU user objects should be tightly controlled.
Delegation tools
You have some help with respect to delegation. This comes in the form of the Active Directory Users and Computers Delegation of Control (DoC) Wizard. The DoC Wizard is available whenever you right-click a container object (such as a domain or OU) within Active Directory Users and Computers. It essentially turns a set of standard tasks you might want to delegate within Active Directory into a template.
It also lets you create custom delegation tasks by picking object classes and choosing what rights you need on those classes. The DoC Wizard stamps a set of permissions you’ve requested on the container with which you’re working.
The DoC Wizard makes simple delegation tasks easy, but it does have several shortcomings:
- It only supports a small set of delegation tasks (though you can extend the set).
- It’s a moment-in-time delegation. In other words, no state of the delegation you just performed is kept. Permissions are simply stamped on the Active Directory objects upon which you’re focused. You can’t modify that delegation through the wizard after the fact. You’d need to go in and manually edit permissions on the ACL directly.
- The DoC Wizard gives you no bird’s-eye view of delegation across your entire Active Directory. Because it’s ultimately just stamping privileges, there’s no way to “keep track” of what delegations you’ve done without looking at the ACLs of each Active Directory object of interest.
Active Directory delegation best practices
A number of best practices have emerged over the years that are worth considering as you determine how to create your delegation model and protect your Active Directory data. A common approach is the “role-based” approach to delegating tasks within Active Directory. This involves listing out the tasks you expect people to perform within Active Directory. This list should be fairly long, as you’ll want to really flesh out all those things you expect people to do against your Active Directory, especially when it comes to modifying sensitive objects.
The next step is identifying those groups of users that need to perform each task or role. By performing this mapping between groups that need access to Active Directory and the types of access you want to support, you’re effectively creating a role-based delegation model you can make real through permissions within Active Directory.
You can design an Active Directory delegation model that breaks security of Active Directory into tasks or roles and then assigns those tasks to user groups. This approach can greatly simplify Active Directory security management and take it from reactive granting of permissions to proactive managing of access to Active Directory data.
Consider all these aspects and how they affect the overall security level of the data stored in your Active Directory directories. Combining and parsing all these techniques can help put your Active Directory data at a safe degree of lockdown.
.jpg "Darren Mar-Elia")
Darren Mar-Elia is a Microsoft Group Policy MVP, creator of the popular Group Policy site gpoguy.com and coauthor of “Microsoft Windows Group Policy Guide” (Microsoft Press, 2005). He’s also CTO and founder of SDM Software Inc. Reach him at Darren@gpoguy.com.
For more on this and other Realtime Publishers titles, check out the Realtime Publishers Web site.