The Role of Roles in Delegating Access

The delegation of directory administration to those outside of IT is a concept whose time has come. But it can’t be done hap-hazardly; IT needs to define what is being delegated and to whom.

We’re at a point in the evolution of our industry that two truths have come to fruition:

• IT no longer has (nor needs to devote) the time to address user access requests
• Users are becoming more technically-minded and security-savvy

Now, if you buy into both of these premises, the idea of delegating access within your directory (something we’ve been advocating for years) and beyond to cloud directories and applications is not only appropriate, but a productive way to ensure the organization is properly secured. Trusted security-minded users know their part of the business better than IT does and can be given the responsibility of addressing individual request of users that reside in their department, utilize the application they own, etc.

But, like every other aspect of security, making one-off assignments isn’t a viable strategy.  Instead organizations should be thinking about delegation in terms of roles. Roles help define what actions can be taken by trusted individuals, ensuring limited administrative ability, and consistency in execution. All this results in IT having confidence that the directory is secure while autonomy is achieved.

Most IT folks will think in basic terms like resetting passwords or an OU Admin. But there are roles other than admin, helpdesk, and user that are possible. For example, the helpdesk can be split up into multiple tiers of delegated control, if desired. Additionally, when you delegate sensitive IT tasks to users (which, at this point is best practice), it is common to have more than one level of access.  Here are a few examples of roles you may consider implementing:

• Reset passwords
• Unlock accounts
• Enable/disable users
• Create groups
• Define dynamic groups
• Manage group memberships
• Create user accounts
• Application-specific capabilities (e.g., Microsoft 365 (and Office 365), G-Suite)

The list above is by no means comprehensive, but it should get you thinking about the tasks each role should be able to perform.  Also, keep in mind that a single role may have more than one of capabilities above.

The next step is to determine the scope of the assigned role – when granting permissions (like those above), it’s imperative to limit the scope to only the appropriate user, group, OU, domain, or application. For example, the head of Sales may be given a role that allows managing group memberships, but only for the department’s group. While it seems simple enough, as the reach of your directory grows well beyond on-prem and ties into countless cloud applications and platforms, the concept of scope becomes that much more important.

IT has a wealth of minions just waiting to assist with offloading day-to-day administrative tasks. Defining and utilizing granular roles will be key as the environment IT is tasked with maintaining grows somewhat exponentially. The granularity of management depends on the what directories, applications, and platforms need to be managed, and the solution(s) in place to centrally manage them all.