Special Reports

The Battle to Provision

The convergence of directory management and provisioning, and how organizations can leverage their directory management investments to meet their provisioning needs.

• By Ezra Duong-Van
• 08/01/2004

The growing use of directory-driven applications and the adoption of Active Directory (AD) are two simmering issues for administrators in large organizations. As a result, adding new users and services, a set of tasks commonly called "provisioning," becomes an even more critical task for IT to manage. For IT managers, the adoption of AD makes Identity Management (IdM) in the organization an easier task, albeit one that's not easy.

Software providers are scrambling to establish themselves as the silver bullet for easy enterprise provisioning. Vendors that made their mark on the enterprise by managing users and groups across a variety of platforms using AD, MIIS, LDAP, and Unix promote this diversity as the answer to provisioning problems. Some enterprises, however, want fewer directories, which positions AD as a means to address IdM. As a result, directory management providers are establishing a foothold in the provisioning space.

This article offers an overview on the convergence of directory management and provisioning, and how organizations can use their existing directory management technology to meet their provisioning needs.

The IdM Landscape
Traditional IdM solutions are designed to address the complex IdM issues of large enterprises. However, other options exist today for smaller, simpler businesses. Below are examples of how and where to add AD provisioning to reduce IdM costs, and ease deployment and maintenance.

Complex: Complex organizations have more than 10,000 users or more than 30 applications that require identity management. In addition, a complex organization might have authoritative identity stores that need replication in a particular order. For example, if an organization has three HR systems (username), messaging systems (e-mail address), and AD (passwords), the replication of usernames, e-mail addresses, and passwords requires bidirectional authoritative replication to ensure that the HR system is the authority for the username, the messaging system is the authority for the e-mail address, and AD is the authority for the password. There might be other identity properties that need replication between directories and applications. All of this requires a metadirectory and significant initial integration effort and maintenance. Typically, comprehensive AD provisioning is not addressed as the focus is managing basic identities in the wide array of directories and applications.

Simple: Simple organizations have fewer than 10,000 users or have fewer applications that will be managed by the IdM solution. Typically, there will be one authoritative store that pushes out identity information to the applications without requiring two-way authoritative replication between many different applications. Much of this can be performed by AD provisioning and pushed out to the applications without a metadirectory.

Hybrid: This simple organization has a complex need. Most of the organization leverages the simple model; however, there might be pockets of applications that require the complex model. For example, 80 percent of the organization relies on AD while the remainder uses other applications. Because the deployment of the complex portion is smaller in scale, the overall solution is easier to deploy and maintain than a standard complex solution.

Leveraging Active Directory Management to Rein in IdM
IdM has become a commonly used term to encompass almost any IT project where a username exists in a directory, metadirectory, or application. With a user's identity appearing in 50 applications and directories (a common occurrence in big organizations), we must find a way to synchronize and manage these "identities" for the user to have appropriate access to the organization's resources. On the other hand, with many organizations deploying separate resources to manage the metadirectory and AD, we are seeing an enormous duplication of efforts, resulting in inefficiencies that hit the bottom line in the form of lost productivity, security breaches, audit failures, and inability to comply with government regulations.

To date, managing identities in most organizations has largely been a manual, time-consuming task that can involve a host of vendors ranging from provisioning, metadirectory, workflow, directory, access control, Web single sign-on (SSO), and password management providers. No single, end-to-end solution for IdM is available today, and none will probably ever exist due to breadth of differences in organizations' IT architecture, topology, and business needs.

New emphasis on automated directory management solutions are presenting alternatives that might reduce IT department operational costs, increase security, and improve productivity. Because of these new implementations, users will also gain access to resources without waiting for IT to configure its identities.

In the sample organization depicted in Figure 1, the user's identity is initiated within HR. The data is exported from the HR application to a holding database and then into a metadirectory. The user data is then passed off to directories and applications. It is common to see the metadirectory connected to as many as 20 applications. Ensuring the integrity of this data and its timely delivery to the endpoint is the purpose of IdM solutions.

This diagram is incomplete because it treats AD in a fashion similar to other targets to which the metadirectory passes off IdM information. AD is unique because it is not only a directory but also the platform for the user's share, home directory, e-mail (if using Microsoft Exchange), access control, and other Windows security settings.

Figure 2 includes typical AD-specific functions that must be performed as part of IdM. Compared to the other directories and applications serviced by the metadirectory, AD requires far more postprocessing once the identity is created in the directory, beyond creating and deleting an identity.

Let's return to the basic business need of IdM: to reduce administration costs and increase security. Analyzing the need for, or the success of, deploying an IdM solution should be rooted in this business case. Typically, an IdM solution concentrates on delivering the identity from the HR application to the directory, not on managing the identity after it is delivered to the directory. For example, an IdM solution can create a user in AD and create the e-mail account, but operations such as retirement, quarantine, promotion, or transfer of that user within the organization are not addressed.

From a resource and cost standpoint, AD-specific operations can be a significant factor in calculating the time to manage an identity. Typically, these processes are AD-specific, and the provisioning employed to automate these AD-only operations has little significance to the other directories or the metadirectory. In addition, the notification and workflow process is typically limited to AD administrators and has little relation to the provisioning or workflow performed at the HR-to-metadirectory phase of IdM.

For simple organizations, it is possible to create a stronger tie between the HR application and AD, ultimately allowing AD-enabled applications to communicate directly with AD, and ancillary or legacy applications to be maintained by way of the metadirectory, if required.

For the IT administrator, this means fewer moving parts, with AD serving as the primary directory. It also means:

• Independence from metadirectory replication or performance for any additions or changes to AD.
• Unaffected core AD should the metadirectory malfunction.
• A more stable environment tolerant of delays or IdM infrastructure failure as only legacy applications are dependent on the metadirectory.
• Immediate availability of provisioned information to AD-enabled applications.

The cost-effectiveness of deployment and maintenance, as well as reliability, has been significant limiting factors toward the success and adoption of metadirectories. While the metadirectory solution for IdM shows cost savings on paper, the scope of these projects is typically limited to supporting critical or easy-to-integrate applications, leaving others to be updated manually. This time and resource-intensive process requires maintaining each provisioning and workflow connector with its respective application, as well as monitoring and troubleshooting replication.

As a result, the cost of deploying and maintaining a metadirectory combined with the operational risk and limited application support, erodes the return on investment (ROI) of metadirectory-based IdM solutions. Moreover, this diminished ROI, although still valuable, loses priority to other projects with a better-defined and lower-risk ROI such as password self-service or SSO initiatives.

Exploring non-metadirectory-based IdM solutions has not been viewed as an option until the recent introduction of comprehensive AD provisioning capabilities offered in new directory administration solutions.

New Options for Provisioning: Directory Administration's Role
New robust directory administration solutions are making it possible for IT administrators to perform extensive provisioning within AD. At the core, these new tools allow data to be manipulated as it changes in AD, eliminating the need to port and provision data to a metadirectory before writing it to AD.

Traditional IdM deployments address the information-provisioning needs, leaving the metadirectory to the applications or destination directories. Many provisioning solutions, however, nominally address the issues of AD administration, which cover all aspects of IdM in AD and includes the operating system (OS) and directory-specific attributes of objects that are more than just identities. Some examples of this are groups, permissions, organizational units (OUs), group policies, services, shares, folders, files, and so on.

Returning to the basic premise of IdM as a cost-saving and security mechanism, it would make sense to not only provision the identity but also all of the associated OS and directory attributes that might affect that identity.

Comprehensive directory administration solutions have the ability to combine user, group, OU, computer account, file, share, printer, service, and any other AD object management. They then apply rule-based provisioning and an approval process to reduce the cost of both IdM and the actual end-to-end business process of managing identities and all other objects associated with the identity.

Rules and templates provide the backbone for provisioning. Rules are condition/action statements that can be applied to objects by OUs. Rules are utilized for the provisioning of almost any AD object and set any properties of the object, as well as group memberships, security, and any other directory or OS attribute or state.

Templates are data-entry overlays that can prepopulate user- or group-property pages. This is a more convenient way to automate data entry, allowing IT administrators to view realtime template information applied to the property sheets.

From a functional point of view, these rules can accomplish everything a template can perform. The administrator experience and usability that templates offer validates their use for data entry operations that require provisioning.

Methods of Provisioning: Rule-Based Versus Role-Based
In rule-based provisioning, rules are applied to any administrative action that triggers an automated event and/or workflow. For example, a rule may move users to the appropriate OU and set their group memberships. If a user is created with the location of "London" and the job title of "Account Manager," the rule will fire and place that user in the sales-sub OU of the London OU and add him or her to the proper groups. Multiple rules typically can be in effect for any one identity or object.

• Advantages: Rule-based provisioning can overlap and be aligned with the business process or the operational policy requirements of an organization. Fewer rules need to be created because they can apply to more than one condition of an object. For example, the "move user to OU and assign group memberships" rule can apply to all users. Exceptions can be easily accommodated in the rule logic.
• Disadvantages: Rule-based provisioning can be complex to interpret because multiple rules can be applied to a single object.

In role-based provisioning, roles are set up within the organization, and actions are assigned to the role. For example, there would be a role called "London Account Managers," and anyone assigned to that role would have his or her OU location changed to London/sales and added to the proper groups. Typically, one role is in effect for an identity.

• Advantages: Role-based provisioning is straightforward and applies a user to a role so that the attributes of that role are applied.
• Disadvantages: Role-based provisioning requires a role for each object state and is relatively inflexible. For example, a role must be created for "London Account Manager," "New York Account Manager," etc. In addition, if there are any exceptions to the rule, a new exception rule must be created. Managing numerous roles increases the manual effort required for maintaining provisioning, and exceptions are not easily handled.

Below are some characteristics to look for in Directory Administration provisioning rules to maximize efficiency:

Rules that are created per object and assigned to an OU. Rules that are assigned to OUs and the rule execution can inherit the OU hierarchy. Rules can also be blocked from inheritance.

Rules that can be created by selecting predefined menu options. It is easy to build rules by selecting menu options and to build condition/action statements. For example, if a user's job title is "Sales," then add him or her to the sales group. This can be accomplished by selecting options from the rule builder without any scripting.

For advanced automation, rules that can pass parameters and execute a script (open ADSI architecture).

Rules that are a collection of condition/action statements. For example, For a Group ? if (condition) ? then (action). Condition/action statements can be chained. For example, For a Group ? if (condition) and if (condition) or (condition) ? then (action) ?(action) ?(action).

Rules that can execute synchronously or asynchronously. Some operations are dependent and need to execute before the next operation can proceed. This would be a case for synchronous actions. Asynchronous actions are used for performing multiple actions that are not dependent or if a particular action has an extended execution time because it needs to reference external data. By executing asynchronously, actions don't have to wait for the previous action to complete before executing.

Actions within rules that can require approvals. Rules are actually "condition ? action ? approval" statements. The approval portion of designing the rule enables a workflow process to be implemented within provisioning.

• Approvals can be manually or automatically approved, which is identical to a proxy method of execution, or might be escalated if not approved within a set amount of time.
• Actions that do not require approval execute under the operator's credentials.
• Actions that are set to auto-approve execute under the approval engine's service account. Actions that require approval execute under the approver's credentials.

To increase scalability, store rules in the AD that can be accessed by a client easily. A client executes rules and templates locally, and the output is written back to AD. Any approvals that might be generated are created at the client level and are then forwarded to the approval server where they notify the appropriate approver that there is a pending ticket waiting. Approvers use a Web interface to approve tickets.

Manual workflow is built into every business process that requires more than one task to be completed. In the IT space, it is common for a business process, such as creating a user, to include many individual tasks that might be dependent on each other and require approvals from different departments or managers.

Originally, developers believed that delegating these tasks to appropriate lower-level and less-expensive operators would help reduce costs. However, this has not been effective because other factors such as supervising and error checking diminish cost reduction through delegation. Delegation also raises serious security concerns because the operator might be granted excessive administrative rights to perform his or her job. By automating the workflow process, organizations can significantly reduce administrative overhead, increase time-to-productivity for a new user, and minimize the risk for security breaches.

The Shortcomings of Delegation
I have three cats: Abu, Cujo, and Sparky. When I travel, I need someone to feed the cats. If I lived in a Windows NT4 House, only I can feed the cats, so either they starve or I never go on vacation. However, because I live in House 2000, I can give other people keys to my house. As such, I give my friend Carl a key, and I delegate cat feeding to him.

I have a big problem, however. Carl can now get into my house, but there is really no way to make sure he doesn't drink all my liquor and order pay-per-view TV. Moreover, he could forget to feed the cats.

Wouldn't it be nice if, when Carl goes to my house, he has to call me when he arrives so I can buzz him in remotely? Once he is in, the TV and liquor cabinet are locked, and I can enforce the rule that he feeds the cats, changes the water, and locks the door when he leaves. With all of those safeguards in place to control his actions, I feel comfortable delegating Carl to feed the cats.

This example illustrates the importance of workflow and approvals that truly make automated provisioning both cost-effective and secure. Table 1 takes a typical business process of creating a user in AD and breaks it down into seven tasks that must be performed. Assuming there is a delegation model in place, this process takes 38 minutes and four people.

The accuracy of the operation is low because more entry-level operators perform several of the critical steps, and there is no mechanism in place to ensure that proper data entry is performed. In addition, the security risk of the operation is high because excessive rights must be granted to the account operator to perform the group membership and home directory tasks. By granting the account operator rights to assign group memberships, and create/permission home directories, the operator has rights to easily subvert security that should be reserved for only the most senior system administrators.

The basis for deploying an IdM solution is to decrease identity administration costs and increase security and compliance. By deploying a comprehensive directory administration solution and utilizing provisioning and workflow, the same user-creation scenario yields very different results in labor and time-to-productivity, accuracy, and risk (see Table 2).

Tasks 2-5 are now automated by provisioning, and the manager in Step 6 approves all actions. This method of IdM achieves the goal of reducing labor, time-to-productivity, improving accuracy, and decreasing risk and related security issues.

This is an example of just one operation of IdM within AD: creating a user. A similar model can be applied to many other IdM and directory management operations such as retiring users, managing transfers and promotions, quarantining accounts, and access control, etc.

Several classes of workflow exist in the market today, including workflow automation and Enterprise Application Integration (EAI). These two classes of workflow are both known as workflow that can cause confusion.

• Workflow-automation products automate business processes that primarily involve people and desktop applications such as word processors and spreadsheets. Workflow automation is concerned with a multilayered, multithreaded process and how to move tasks through this process.
• EAI products automate business processes that deal with enterprise applications such as IdM, ERP, CRM, Supply Chain Management, and Sales Force Automation. EAI is focused on events triggering actions based on conditions that are not typically multilayered or multithreaded.

Operations
Figure 1 illustrates a common task list for creating a user. IdM encompasses many other tasks that are outlined in this section. Note that any of these operations can be applied to users, groups, mail recipients, OUs, and other directory objects not considered under IdM including machine accounts, distribution lists, sites, and Domain Naming Service (DNS) entries.

There are approximately 300 other object types in AD, which can easily grow to more than 700 with the introduction of Microsoft Exchange. Although the majority of administrative overhead is limited to the common object types—users, groups, OUs—automating management of these other objects using provisioning and workflow capabilities helps organizations achieve additional cost savings. In other words, directory administration tools can reduce IdM costs as well as other OS and directory management processes. Operations that can be performed include:

• Create: Create users and groups.
• Delete: Delete users and groups.
• Quarantine: Disable an identity, move the identity to a secure OU so that only senior administrators can restore that identity to operational status, alleviating the risk of the help desk unlocking sensitive identities without administrative intervention.
• Move: Moving an identity between geographies and politically within the organization. This includes revoking and reassigning permissions, group memberships, identity properties, location of home directory, mail store, and other attributes.
• Promote: Changing the job function of an identity.
• Retire: Decommission an identity, remove all rights and security settings, and archive personal data and mail assigned to that identity. Retired identity might be placed in a secure holding OU for a period of time before it is deleted.
• Help desk operations: Help desk operations include day-to-day help desk intervention to fix identity errors or errors related to access controls, configuration, group memberships, etc. Although these operations are typically performed on a one-off basis, they are outside of the scope of traditional IdM automation but still can benefit from automated provisioning and workflow.

Deployment Considerations
Several factors will drive the decision to implement an IdM solution. With the ultimate goal of lowering IT administration costs, one of the most important areas to evaluate is the cost of designing, deploying, and maintaining the solution. Once an IdM solution is deployed, there are maintenance and administrative costs to keep the IdM solution performing properly, so achieving a clear return on investment quickly will be paramount.

Before deploying any IdM, it is critical to outline the organization's strategic goals. Reviewing the following criteria should help:

• Identify the platforms where identities exist. There might be multiple identity starting points due to multiple HR applications, mergers and acquisitions, or a disparate business unit's political or geographical requirements. If possible, consolidate these starting points. Then, identify identity destinations, which could include LDAP directories, AD, applications, SSO, and so on. Consolidate or streamline destinations whenever possible to significantly reduce IdM efforts. For example, if newer versions of an application are LDAP- or AD-enabled, these applications should be deployed first. Applications that have proprietary directories might require significant work to integrate and maintain for an IdM solution, and the option of not integrating these applications into the IdM (continuing to manually update these applications) might be the most cost-effective route.
• Identify the policies and processes for maintaining identities. Each application, LDAP directory, or AD will have unique requirements for creating and maintaining the identities. This should be discovered for each platform.
• Identify the specific identity needs of each supported platform. Some applications might simply need an account name and role, while others such as AD require all user properties, home directory, share, group memberships, e-mail (if using Microsoft Exchange), and other AD security attributes. The identity needs should not be limited to identity creation and should include the complete identity lifecycle management.
• Identify which of these needs can be automated. Depending on the platform, identity information may be drawn directly from a centralized identity store like a metadirectory or AD. Additional identity information might need to be retrieved from other systems, manually entered, or automatically created, based on existing identity information. Approvals might be required as part of the automation process.
• Identify what data needs to be replicated and if authoritative stores are necessary. Traditional IdM solutions address scenarios where there are multiple authoritative stores that need to pass data back and forth. An example of this is an HR application that is the authoritative store for the name, an e-mail system that is the authoritative store for the e-mail address, and a directory, which is the authoritative store for the password. These three identity attributes (name, e-mail address, and password) must be passed from their respective stores, reconciled, and passed to the applications. This might not be necessary in some scenarios, as AD can be the authoritative store for all of this data and the need for managing multiple authoritative stores is eliminated.
• Evaluate the software and services that are needed to deploy and maintain the solution. This includes provisioning, workflow, metadirectory, directory, application upgrades or connectivity modules, and directory management tools.
• Create a service-level agreement (SLA) that encompasses the previous points. Evaluate the proposed IdM process including latency issues, reliability, and disaster recovery issues related to the IdM system. Based on these requirements and the resources needed to achieve these requirements, an SLA can be created.
• Calculate the costs for each of the previous points. Include costs for the following: manual cost for maintaining your existing method of IdM; appropriate platforms to automate and the associated cost savings of automating each platform; and the cost of deployment and maintenance of the IdM solution—IdM provisioning, workflow, metadirectory, management software, application upgrades, connectivity modules, and services.
• Develop a schedule for deployment. The schedule should include a proof-of-concept plan, a pilot, a phased-deployment overview, and available application upgrades.

Deployment of an IdM solution is rarely an all-or-nothing scenario. Typically, it won't make financial sense to include all applications in an IdM, and only those business applications that are easily integrated are included. Because the costs of deployment and maintenance typically outweigh the actual cost of the software, it is important to evaluate the application-upgrade schedules carefully. Sometimes, future versions of business-critical applications may negate the need for developing custom connectors for that application today.

Compliance Issues
Although the traditional reason for deploying an IdM solution has been to reduce overall IT administrative costs, security and compliance issues are fast becoming an even greater influence in the decision.

Industry estimates for internal security breaches vary widely, ranging from 40 percent to more than 80 percent, which suggests a significant portion are related to managing identities. Proper IdM, based on policy and enforced by an IdM solution, could reduce these types of breaches significantly.

Identity-related security breaches are usually related to:

• Misconfigured accounts
• Stale accounts
• Contractor accounts
• Service accounts
• Excessive granting of administrative rights
• Promoted or transferred employees retaining old rights
• Retired employees still in the system
• Users not properly quarantined from network access

Directory administration solutions not only address all of the security and compliance issues pertaining to AD identities, but also security and compliance issues related to the OS such as services, shares, distribution lists, access controls, etc.

Although IdM is a broad topic that can be interpreted and deployed in many variations, the underlying drivers for deploying these solutions are cost savings, security, and compliance. Rather than strictly looking for ways to minimize or eliminate human intervention, these goals should be carefully considered through the process of designing and deploying an overall solution. Depending on the organization, the IdM solution itself could increase costs.

Conventional wisdom holds that provisioning, workflow, connectors, and metadirectories need to manage identities between different platforms and applications, while emphasis on more complex AD provisioning is overlooked typically. Using traditional provisioning and workflow tools is well suited for provisioning data entering AD, but little attention is given to the ever-changing data within AD. This was left to the help desk or the IT department to change using a help ticket.

With the introduction of new directory administration solutions into an IdM deployment, there are now other available options. These options range from using tools in conjunction with a traditional IdM deployment to address the complexities of AD provisioning, to using AD as the common identity store where provisioning takes place and is sent to other identity destinations (see Figure 3). As AD-aware applications continue to be available, directory administration tools enable a much simpler IdM solution based entirely on AD.

Directory administration vendors can provide a complete suite capable of managing users, groups, and numerous other critical IT initiatives such as security and policy compliance. Finally, by extending the directory management investment to meet provisioning needs, customers can realize a higher return on investment through economies of scale and a richer, deeper set of product capabilities.

About the Author
Ezra Duong-Van is a director in BindView's Corporate Strategy Group. He has more than 15 years of experience in the design, installation, and maintenance of computer systems and software.