The Top Five Active Directory Management Pain Points

Quite possibly even more critical to your enterprise than your most valued application or your most protected intellectual property is your Active Directory (AD) environment. Active Directory is central to your network, system, user and application security. It governs access control for all objects and resources within your computing infrastructure and at considerable cost in both human and in hardware resources required to manage it. And thanks to third-party software vendors, you can also add Linux, UNIX and Mac OS X systems to AD’s repertoire of managed resources.

Managing AD for more than just a few dozen users and groups becomes very painful. And Microsoft’s basic interface and organization is no help to relieve that pain. Active Directory isn’t a weak tool, but there are aspects of it that leaves administrators searching for third-party tools. This piece explores AD’s top administrative shortcomings.

1. Dealing with Nested Groups

Believe it or not, there are actually best practices associated with creating and using nested AD groups. However, those best practices should be tempered by built-in AD restrictions, so that administrators aren’t allowed to extend nested groups to more than a single level. Additionally, a restriction to prevent more than one nested group per existing group would prevent future housekeeping and administrative problems from arising.

Nesting multiple group levels and allowing multiple groups within groups creates complex inheritance problems, bypasses security and ruins organizational measures that group management was designed to prevent. Periodic AD audits will allow administrators and architects to reassess AD organization and correct nested group sprawl.

System administrators have had the “Manage groups, not individuals” credo pounded into their brains for years, but group management inevitably leads to nested groups and poorly managed permissions. (Learn about Softerra Adaxes role-based security here.)

2. Switching to RBAC from ACLs

Switching away from a user-centric access control lists (ACLs) AD management style to the more enterprise method of role-based access control (RBAC) seems like it would be an easy task. Not so with AD. Managing ACLs is difficult, but switching to RBAC is no walk in the park either. The problem with ACLs is that there’s no central location in AD to manage permissions, which makes administration challenging and expensive. RBAC attempts to mitigate permissions and access failures by handling access permissions by role rather than by individual, but it still falls short because of the lack of centralized permissions management. But, as painful as moving to RBAC is, it’s far better than manually managing permissions on a per-user basis with ACLs.

ACLs fail scalability and agile manageability because they are too broad in scope. Roles, alternatively, are more precise because administrators grant permissions based on user roles. For example, if a new user at a news agency is an editor, then she has the role of Editor as defined in AD. An administrator places that user into the Editors Group that grants her all permissions and access that Editors require without adding the user to multiple other groups to gain equivalent access.

RBAC defines permissions and restrictions based on role or job function rather than assigning a user to multiple groups that might have broader permissions. RBAC roles are very specific and do not require nesting or other ACL complexities to achieve better results, a more secure environment, and a more easily managed security platform.

3. Managing Computers

Managing new computers, managing computers that have become disconnected from the domain, and trying to do anything with computer accounts makes administrators want to head to the nearest Martini bar – for breakfast.

The reason behind such a dramatic assertion is that there are 11 words that you never want to read on a screen as a Windows Administrator: “The trust relationship between this workstation and the primary domain failed.” These words mean that you’re about to spend multiple attempts and possibly multiple hours reconnecting this wayward workstation to the domain. It’s unfortunate that the standard Microsoft fix doesn’t work. The standard fix consists of resetting the computer’s account object in Active Directory, rebooting the workstation, and crossing one’s fingers. Other reattachment remedies are often just as effective as the standard one, causing administrators to reimage the disconnected system in order to reconnect it to the domain.

4. Handling User Account Lockouts

There’s no self-service fix for account lockouts, although several third-party software vendors have solved the problem. Either users have to wait for a time period before retrying or to contact an administrator to reset the locked account. Resetting a locked account isn’t a point of stress for an administrator, although it can prove frustrating for a user.

One of AD’s shortcomings is that account lockouts can originate from sources other than a user entering an incorrect password, but AD doesn’t give the administrator any hints as to that origin.

5. Permission Elevation and Permission Creep

There is a potential for privileged users to further elevate their privileges by adding themselves to other groups. Privileged users are those who have some elevated privileges, but who have just enough authority to add themselves to additional groups, which grants them additional privileges in Active Directory. This security flaw allows an internal attacker to add privileges in a stepwise manner until extensive control over a domain exists, including the ability to lock out other administrators. (Eliminate resource-consuming manual procedures in Active Directory Identity Management. Learn how here.)

Permission creep is a condition that occurs when administrators fail to remove users from a particular privilege group when a user’s job changes or when a user leaves the company. Permission creep can allow users access to corporate assets for which the user no longer has need. Permission elevation and permission creep both create serious security concerns. Various third-party applications exist that can perform audits to detect and to prevent these conditions.

From small companies to global enterprises, Active Directory handles user authentication, access to resources, and computer management. It is one of the most valued pieces of network infrastructure in business today. As powerful a tool as Active Directory is, it has many shortcomings. Fortunately, non-Microsoft software vendors have extended Active Directory’s features, resolved its poorly conceived management interface design, consolidated its functionality, and massaged some of its more glaring inadequacies.

This content is brought to you by our partner, Adaxes.