It would not amount to an exaggeration to state that the Active Directory (AD) environment is of greater value than intellectual property or any software application of an enterprise. Active Directory is the most vital resource that plays an important role by supporting system, network, application system and user.
AD can also accommodate huge gamut of managed resources including third party resources such as Linux, MAC OS X, and UNIX. It also administers access control for all resources and objects within enterprise computing infrastructure and requires overwhelming costs to manage manpower and hardware.
There are considerable hurdles for managing Active Directory for limited number of users and groups. In spite of its robust performance and wide ranging functionalities, there are distinct limitations of Active Directory that need to be discussed at length. These pain points can hardly be relieved by accessing Microsoft’s basic interface.
Managing nested groups
Creating and using AD nested groups is associated with best practices. It must be noted that built-in AD restrictions must be used to slightly modify these best practices. This would prevent administrators from extending nested groups to more than a single level. Prevention of more than one nested group for each existing group will ensure that future administrative issues in terms of administration and house-keeping are avoided.
Permitting multiple groups within groups and nesting multiple group levels amounts to complex inheritance problems in addition to bypassing security. This would also ruin organizational measures that were designed to be prevented by group management. Nested group sprawl can be corrected by implementation of periodic AD audits. Such audits are also useful to help administrators and architects reassess AD organization.
Shifting to RBAC from ACLs
Shifting away from user oriented Access Control Lists (ACLs) as per AD management style to enterprise method of Role Based Access Control (RBAC) may appear to be a smooth transition. Practically speaking, the converse is true since it is very difficult to manage and switch to ACLs. It is the same story while switching to RBAC. Active Directory lacks central location for managing permissions and results in a complex and expensive process.
RBAC tries to reduce permissions for accessing failures. This is achieved by handling access permissions by role instead of individual. However it is not able to succeed hands down due to lack of centralized permissions management. In comparison with the difficulty level of moving to RBACs, it is much easier to manage permissions manually with ACLs on per user basis.
ACLs fall short of scalability and dynamic manageability due to the fact that these are too broad in shape. In contrast, roles are more precise because the permissions are granted by administrators based on user roles.
RBAC considers a job function or role for defining permissions or restriction instead of assigning a user to several groups that could have facilitated broader permissions. RBAC do not need other ACL complexities or nesting for delivering superior results in addition to greater security of environment or a security platform that is managed easily.
Administrator’s worst nightmare is to spend long hours and unending attempts to reconnect errant computers that are disconnected from the domain. This a common phenomenon while managing new computers or workstations that are no more connected to domain.
Unfortunately, the standard Microsoft solution is not able to provide any solution. Following the standard fix means resetting the workstation’s account object in Active Directory and rebooting followed by praying for the desired result.
Alternative remedies are in no way better than the standard fix either. The options involve reimaging of the disconnected system for the purpose of reconnecting the same to domain.
Managing user account lockouts
Account lockouts do not offer any self service fixes. There are few third party fixes that have found some solutions to this issue. This may involve long periods of waiting for accessing the administrators for resetting the account.
The process of account resetting can be highly irritating for the user rather than the administrator. The significant issue regarding user account lockout events is, these need not necessarily arise out of incorrect password. It can also originate from sources and Active Directory offers no clue to the admin guy about the origin.
Serious security concerns related to user permissions
Privileged users are capable of elevating their privileges by simply including themselves to other groups. Privileged users are able to elevate themselves to acquire additional privileges in Active Directory environment. Such feature of permission elevation can prove to be major threat to security. The feature can be exploited by a privileged user to progressively get elevated by adding privileges till the time the user is able to gain extensive control to the extent of locking out other administrators.
Whenever the administrators do not remove user from a specific privilege group on account of change of job or profile the condition is termed as Permission Creep. This can lead to an unauthorized person gaining access to corporate assets that are not supposed to be used by the particular individual.
Permission elevation as well as permission creep are potential threats to security. Users can access multiple third party applications for performing audits for detection and prevention of such eventualities.
Active Directory is one of the most vital resources to facilitate user authentication, computer management, and access to various resources. It is an important piece of network infrastructure for modern enterprises. In spite of its robust attributes Active Directory suffers from multiple limitations.
It is encouraging to note that some non-Microsoft software vendors have offered to extend features of Active Directory by effectively resolving its mediocre management interface design and strengthened its functionalities by polishing some obvious shortfalls.