by 

So far, we’ve discussed the increasing importance of Active Directory (AD) within the identity management life cycle (Chapter 1) for most organizations, and we’ve talked about some of the finer points of that life cycle (Chapter 2). This chapter is dedicated to the point that, if AD is going to be a key part of your identity strategy, you have to protect it. You have to ensure that the data within AD is sacrosanct and that only those with a business reason to access AD information are granted that access.

This chapter provides a practical guide to protecting your AD-based identity data. It is not part of the life cycle I spoke about in earlier chapters, but it is an important part of ensuring that any identity system you implement that leverages AD is protected such that it is able to do its job of authenticating and authorizing the right people to the right resources. All the great identity provisioning processes in the world won’t help you if your AD is a free-for-all that anyone can fiddle with to their heart’s content. This chapter will dive into the AD security model and provide techniques and best practices for securing the data that resides in AD.

The Challenges of Securing AD

We wouldn’t have to dedicate a whole chapter to managing AD’s security model if the model was straightforward and simple. But the nature of a hierarchical directory service that serves many purposes (for example, application directory, authentication directory, desktop management directory, etc.) is such that the security model can be a handful. More importantly, if you don’t take a proactive approach to managing the security of your AD, it can quickly get out of control. Take, for example, the simple task of delegating management of user accounts in AD. Because of the granular nature of the AD security model, managing user accounts, while seemingly a simple task, could break down into a dizzying array of permissions that must be delegated:

• Permission to create user objects
• Permission to delete user objects
• Permission to move user objects
• Permissions on properties on the user object (may break down into sensitive, such as department, manager, group memberships, etc.) versus non-sensitive (telephone number, office address properties)
• Permissions to reset the user’s password or unlock their account
• Permissions to control who can change a user’s permissions

This list is not comprehensive, but it underscores the possible complexity of managing delegation on just this one task. Take into consideration that each of these tasks (or at least groups of them) might be delegated to sub-groups of administrators, and that these permission sets might vary based on what OU a set of users are in. Throw into the mix that permissions can be inherited from parent objects in AD to their children (for example, from the Marketing OU to the Users OU under Marketing), and things can really get gummed up if you’re not careful.

Not only is the complexity of AD’s security model challenging (more on this later), it requires discipline to establish a good delegation model and keep it that way over time, as the one-off requests and unusual business needs drive you to make compromises in that model. At the risk of being overly dramatic, “That way madness lies.” Over the years, I’ve seen so many AD delegation plans get mired in over-complexity and intricacy so as to be completely unusable over time. If our ultimate goal is to protect the data in AD that is critical to your organization’s authentication and authorization mechanisms, then it’s important to get and keep a handle on AD security. We’ll talk about how to do this later in this chapter, but now let’s dive into more detail about how AD’s security model works.

Click here to download this chapter or book.

Tags: Active Directory