How To Manage End Users

Updated: August 20, 2012

The larger the organization and its IT infrastructure, the more time and resources it must devote to providing appropriate system access to end users. A study by Forrester Research Inc. found that it takes 6 to 17 minutes to provision one new user on a single enterprise-scale system. In many cases, a new user must be provisioned on 10 to 20 different systems in order to do his or her job. Requests for access must be routed through different system administrators , delaying the new user's full productivity.

Then there are constant changes that must be made to users' access privileges. In today's enterprises, people change jobs, locations and responsibilities all the time. Each change may require updates of system-access privileges.

Finally, IT must remove users who are no longer with the company or who no longer have a need for access to a particular system. This is especially important in light of legal and regulatory initiatives such as the Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes-Oxley Act .

Multiply all of that by hundreds or thousands of employees and it's no wonder that many organizations employ multiple user administrators. And still, delays in provisioning users and deactivating unneeded privileges continue.

Most organizations have turned to third-party user-management software to consolidate and streamline their user-management processes.

User-Management Software

Third-party user-provisioning software, such as IBM Corp.'s Tivoli Identity Manager, automates some subset of the following functions:

Automation and Change Propagation: Changes made to user profiles on human resources or contractor-management systems trigger automatic updates to the same users' profiles on all other systems the user needs to access.

Self Service: Users or automatic processes submit change requests. Requests are routed to business users with authority to approve or reject them. Approved changes are applied to other systems automatically.

Consolidation: Companywide security administrators update user access to multiple systems from a single security-administration console that creates a consolidated view of multiple security databases.

Delegation: Regional or departmental security administrators are granted limited access to manage some users on certain systems through the consolidated security-administration console.

User-management software generally makes use of role-based access control, a method that has its strengths and weaknesses.

Role-Based Access Control

Where users can be grouped by a set of identical system-access needs, RBAC (role-based access control) makes sense. Instead of provisioning each user individually, the administrator defines a role — such as "store clerk" or "reservationist" — and assigns system-access privileges to that role. Then users are assigned roles and gain the privileges associated with their roles. When it is time to change the privileges, only the role must be updated.

Of course, users are not exactly identical. They have attributes that are not taken into account by roles. So administrators implement dynamic logic rules that are keyed to user attributes such as location or store number. This would allow assignment of a suitable email server to a store clerk in store 121, for example.

Problems arise when individuals do not fit any of the predefined roles. Then changes must be made to individual user profiles, creating a whole new role. It is also difficult and costly to define roles across multiple heterogeneous systems. RBAC works best on standard, static user profiles that apply to large groups of employees on a single system, such as an Oracle Corp. database . It doesn't work well when dealing with managers, accountants, engineers and others who have unique access requirements that cross system boundaries.

Large organizations tend to have a lot of unique users, each of whom must be assigned a role. The proliferation of roles can diminish the benefits of using an RBAC system, because the roles themselves become cumbersome and costly to manage.

Changing Roles

Even if a company can design an adequate yet not-too-large set of roles, it must still deal with the fact that role definitions and user classifications change over time. Routine events, such as changing an employee's responsibilities or extending the function of a department, require role models to be adjusted. A team of expensive experts can be kept busy just by continuously adjusting role models to reflect the constant evolution of the business.

Less frequent, but more disruptive, are major changes such as mergers and acquisitions. Then a large team of experts must be hired to make massive changes to the role models and reclassify many employees.

The effort required to maintain the role models can easily be larger than the cost savings achieved by eliminating some or all manual user administration. Also, administration of the role models requires more skilled — and therefore more expensive — staff than manual user administration.

Request-Based User Administration

Because of the challenges inherent in using a full RBAC user-administration strategy, most organizations supplement RBAC with some form of request-based user administration. These systems can use Web-based forms to send an email request to an appropriate authority asking to approve or reject the change. Approved requests are then propagated to the appropriate systems.

It is more complicated than that in practice. Automated systems must perform many tasks to ensure that users' requests are valid, that administrators respond and that the approved change actually gets implemented. They also generate reports on requests, wait times, approvals and so on.

The combination of RBAC and request-based user administration seeks to strike a balance. Many system-access needs can be met by RBAC. Exceptions are handled by requests. This takes routine burdens off the shoulders of user administrators while preventing the role model from growing too large with unique roles.

But request-based user administration opens the door to yet another problem.

Privilege Accumulation

Users can accumulate privileges outside of their roles under request-based user administration. When a user changes roles, he or she may retain some of the requested privileges even though they are no longer needed. Excessive privileges are a serious security concern .

The simplest solution, and one used by many organizations, is to periodically audit user privileges and remove those that are no longer needed. It would be impractical to audit thousands of users from a single point, so this task is typically delegated to direct supervisors and to owners of the applications or data to which users have access.

Ensuring that security audits actually get done can be difficult in a large organization. There may be hundreds of thousands of direct supervisors. One way to enforce compliance is to require departmental managers to certify the audits submitted by their reporting supervisors. This keeps downward pressure on supervisors to get their audits done.

Managing users in a large, heterogeneous and distributed organization is very challenging. A combination of RBAC and request-based user administration, with periodic security audits, is the best that can be done at this time.