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.
|Softerra Adaxes automates, streamlines & secures Active Directory Provisioning.
Download the trial version FREE.
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.