Organizational User Provisioning: Comparison of · PDF fileOrganizational User Provisioning: Comparison of Common Methodologies ... Blackberry Enterprise Server 4.1.4. ... For larger

Organizational User Provisioning: Comparison of Common Methodologies

Executive Summary

This document is intended to summarize and compare the common approaches to user provisioning and access control within medium size organizations between roughly 1,000 and 5,000 employees. For the purpose of this document, user provisioning is defined as the process of creating an account authorizing access for an individual to specific application services including email and associated mobile devices supporting push email. The three common approaches include:

1. Use of native tools (manual provisioning)

2. Shell scripts (semi-automated provisioning)

3. Complete provisioning platform (fully-automated)

In summarizing the common approaches, this document provides detailed, screen-by-screen snapshots describing each step in the provisioning process while keeping track of the length of time necessary for each step. We also describe the general requirements, summarizing the advantages and disadvantages of each respective approach. This document will cover the provisioning process with the assumption that users need to be given support for:

! Microsoft Active Directory, including appropriate security and distribution group list membership (and thus also access to any systems utilizing AD’s schema for access or identification);

! Exchange 2007 (including desktop and Blackberry support), and ! Blackberry Enterprise Server 4.1.4.

The approaches that are documented include:

! Use of native tools including the Microsoft MMC console for Active Directory, the Exchange management console (EMC) for Exchange 2007 and Blackberry Manager.

! This example demonstrates the variety of attributes of an account that need to be managed during the provisioning process using the separate interfaces provided by each of the tools mentioned above.

! Use of shell scripts that have been provided by third parties or created and managed by the organization itself to facilitate provisioning across these platforms.

ORGANIZATIONAL USER PROVISIONING: COMPARISON OF COMMON METHODOLOGIES 1 20 FEBRUARY 2008

ORGANIZATIONAL USER PROVISIONING: COMPARISON OF COMMON METHODOLOGIES 2

! Use of Ensim Unify Enterprise as the user provisioning and access control solution.

It is important to keep in mind that procedures can vary in different environment even when similar tools are used. Also note that the workflow and process ownership can be distributed by geography or functional area. For that reason, a common example of the required information and steps will be utilized. Our goal is to provide an understanding of the

! information required to complete the provisioning process ! the steps of required for approval and workflow ! the range of IT skill sets required ! the requirements for systems access and infrastructure for each approach ! an overview of the relative strengths and weaknesses of each approach

Process Flow

The user provisioning process usually involves a number of functional areas where expertise and process ownership are allocated. These include human resources (HR), IT, facilities, those responsible for allocating mobile devices and the team responsible for the corporate messaging infrastructure. For the purpose of these examples, it will be assumed that:

! The HR organization will work with employees to identify a start date, complete salary and tax paperwork, and perform other tasks related to the employment process both from a new hire and termination perspective.

! Facilities provides a location for the new employee and related items. ! IT provides a computer, Blackberry and the account definition (the list of approved

service components, security group and distribution list assignments, and recommended service configurations. The account definition prescribes the access level and capabilities of the account to be provisioned (ex: Employee, Contractor, Executive Management, etc).

! The examples begin with a request to generate a new account for the user so that, on their start date, they would have access to the organization’s network and resources, email, and Blackberry. The provisioning administrator (whether it is a help desk staff or the IT administrator for the enterprise) is assumed to be tasked with processing the request consistently per the documented methodologies and policies defined by IT department.

Summary of Findings

Automated provisioning using a complete provisioning platform such as Ensim Unify provides:

! an 8X efficiency improvement over manual provisioning and de-provisioning ! a 4X efficiency improvement over use of shell scripts for the provisioning process ! Unify makes it easy for IT to support the full range of mobile devices (smart phones) ! provide a standardized yet extensible architecture that meets compliance and security

audit requirements

20 FEBRUARY 2008


Traditional Approach Using Native Tools

The use of native tools is common to smaller environments and those where entrusted, knowledgeable administrators either insist on, or are required to retain, control of these tools.

! Phase 1: Creating an Active Directory Account

1 Accessing Active Directory Users and Computers Console

(Approximately 1 minute from start) The screen at left illustrates the launch of the Active Directory Users and Computers Console, which is generally located on a domain controller and accessed using a domain administrator account.

An administrator will need to get access to and login to, the machine where this tool resides, using an account privileged to create AD accounts. For larger inter-site environments, a specific domain controller in the appropriate site may have to be accessed for the following steps.

The administrator would then need to select the appropriate Organizational Unit for the account, to utilize the environment’s group policies assigned to each Organizational Unit. This would need to be documented and consistently performed with each provisioning to appropriately locate the account within the Organizational Unit hierarchy, which can be complex in larger and more sophisticated AD deployments.

(Organizational Units are commonly used to separate Users, Computers and Active Directory objects by functional area, geography, business lines etc.)

After selecting the appropriate Organizational Unit, the administrator selects the new user function via the menu or the button on the toolbar.

2 Creating the Active Directory Account (Approximately 3 minutes from start)

The administrator will then provide the name and login ID for the account. There will generally be an established approach to generating login IDs that would be well documented and understood by the Active Directory provisioning staff. The login ID must be guaranteed unique to the Active Directory domain, and so an administrator should check and search for the preexistence of the intended login name dictated by the login naming convention procedure.

In case the intended login name is in use, the procedure for generating unique login IDs would need to address these exceptions and outline a common methodology of extending the ID to become unique. Common approaches are to append numbers, include middle initials etc. (example: John.Doe becomes John.J.Doe or John.Doe01)

20 FEBRUARY 2008


3 Creating the Password and Password Policies for the AD account

(Approximately 6 minutes from start) The administrator will then provide a password (with verification) for the account.

There are also options regarding changing the password and expiration that should be consistently selected according to the organization’s policies. These policies generally vary for particular roles or account types within the organization.

Exceptions may exist on the password policies for certain accounts, and both the strategy for creating a password and the options/exceptions for password policies need to be understood across the Active Directory team for consistent enforcement.

4 Creation of the Active Directory Account

(Approximately 7 minutes from start) The initial task of creating the Active Directory account will be completed upon selecting Finish from the last confirmation dialog, providing the account logon name, and the password policy selections.

20 FEBRUARY 2008


5 Assigning extended Active Directory information

(Approximately 9 minutes from start) Once the account is created, it would be located and opened so that additional AD information can be provided for the account that is not required in the initial account setup (such as address, office location, telephone, mobile telephone, fax, title, department etc.)

A manager can also be designated from the existing accounts under the Organization tab.

In many cases, organizations may leave the entry of this information to another functional area within the organization, or to the account owner themselves (requiring notification to, and involvement of, this participant entity).

There also may be extended Active Directory attributes required internally for other applications or processes, and this would be the ideal phase for these to be entered.

6 Assigning of Account Restrictions, Logon Hours, Systems Available for Logon etc.

(Approximately 14 minutes from start) The organization may require restrictions in terms of logon hours, and specific systems available for login for the functional role/account type the user will be assigned to.

An account expiration may be assigned for temporary accounts (contractors, interns, consultants etc.)

Again, this would be dependent on the policies in place for certain roles, and the common methodology that has been documented and trained on for account creation.

20 FEBRUARY 2008


7 Designating User Profile Location, Login Script, Home Directory for the Account

(Approximately 15 minutes from start) The administrator can then configure the User Profile to be stored on a network resource, as is common for ensuring backup and availability of the profile across the organization.

Additionally, a login script can be designated for specific actions to take place for the specified role upon login (mapping of drives, system configuration, etc.)

The account’s home directory can also be mapped to a network resource (as is a common practice for larger organizations), to ensure backup and availability of the account’s home directory.

8 Assigning of Security Groups, Distribution Lists and other Active Directory Attributes

(Approximately 17 minutes from start) A critical piece of adding an account to the environment is to also designate the security groups and distribution lists appropriate to the employee role.

This allocates permissions (in addition to the policies enforced at the Organization Unit level) to resources throughout the enterprise. This is another critical piece of documentation for the provisioning of different roles within the organization, and any exceptions to the standard methodology would need to be provided to the provisioning staff. A failure to allocate the proper distribution lists and security groups will result in unreceived correspondence, inability to access critical resources, or creating a security hole by availing improper resources.

9 Selecting the Appropriate Security Groups and Distribution Lists for the AD Account

(Approximately 18 minutes from start) A critical piece of adding an account to the environment is to also designate the security groups and distribution lists appropriate to the employee role.

This allocates permissions (in addition to the policies enforced at the Organization Unit level) to resources throughout the enterprise. This is another critical piece of documentation for the provisioning of different roles within the organization, and any exceptions to the standard methodology would need to be provided to the provisioning staff. A failure to allocate the proper distribution lists and security groups will result in unreceived correspondence, inability to access critical resources, or creating a security hole by availing improper resources.

20 FEBRUARY 2008


10 Selecting the Dial-in, Remote Control and Terminal Services options for the account

(Approximately 22 minutes from start) It should then be determined whether to allow Terminal Services sessions toward the account, and whether it is required for them to accept these requests. You can also enable remote assistance sessions to have a view-only, or complete interactivity during Terminal Services sessions for the account.

Alternate profile and home directories can be specified within the Terminal Services Profile tab, to redirect profiles and home directories during Terminal Services sessions.

Additionally, using the Dial-In tab, permission can be granted and configured for remote access to the environment (including VPN), and whether a callback number is required (for dial-up access).

11 Setting Appropriate Permissions to the Account and Completing the AD Configuration

(Approximately 25 minutes from start) Finally, configuration of permissions of the new account for other security groups and specific accounts would need to be configured according to the methodology for the intended account role. Again, this would need to be documented and consistently applied to accounts according to intended capabilities, and exceptions would need to be authorized, outlined and recorded according to the provisioning methodology.

These permissions can be complex in larger organizations and more sophisticated AD architectures, and improper configuration can lead to complex problems in administering and supporting the account once it becomes active.

Any accompanying documentation or required notifications would need to be generated so that the appropriate stakeholders and subsequent processing participants are provided relevant information per their requirements.

This effectively creates the account within Active Directory, and replication across Active Directory sites will eventually populate the Global Catalog servers throughout the domain with the account information. The time required for the account to fully propagate throughout the domain(s) is determined by the inter-site replication strategy, which can be anywhere from one hour to several days depending on the number of sites, WAN links/speeds and Active Directory site complexity.

20 FEBRUARY 2008


Phase 2: Creating an Exchange Mailbox for the User

The next phase is to create an account within Exchange for the user. This may be a process that is owned by another functional area within the organization (particularly in larger environments where Active Directory and Messaging Services may be divided), so there may be a required documentation, notification and handoff before the procedure may continue.

12 Accessing Exchange Management Console

(Approximately 30 minutes from start) This screen illustrates the launch of the Exchange 2007 Management Console, which is generally located on an Exchange 2007 server, or a computer on which the Exchange management utilities has been installed (a partial install of the Exchange platform).

The administrator will need to access and login to the machine where the Exchange Management Console has been installed, using an account that has rights to create mailbox accounts (generally Exchange Administrator or equivalents).

In many (particularly larger) organizations, this functional responsibility may exist outside of the Active Directory group, and so a handoff of the procedure may be required.

13 Starting off the new mailbox procedure within Exchange Management Console

(Approximately 32 minutes from start) Once the management console for Exchange has been accessed, a new mailbox for the new account can be created by selecting the Mailbox component under the Recipient Configration portion of the interface.

By selecting New Mailbox…, the new mailbox wizard will be presented to the administrator.

20 FEBRUARY 2008


14 Selecting the Mailbox Type and the Account that will its Designated Owner

(Approximately 33 minutes from start) Once the management console for Exchange has been accessed, a new mailbox for the new account can be created by selecting the Mailbox component under the Recipient Configuration portion of the interface presented above.

By selecting New Mailbox…, the new mailbox wizard will be presented to the administrator. (The example screen at left shows this phase of the new mailbox wizard.)

15 Locating and Selecting the New Account and Assigning it to the New Mailbox

(Approximately 33 minutes from start) By selecting the Existing Users radio button (illustrated above) and then the Add… button, a search screen is presented to locate the account to which this new mailbox will be assigned.

Upon selecting the account, selecting OK returns you to the prior screen (shown below) with the chosen account presented within the list box.

16 Confirmation of Selected Mailbox User Account

(Approximately 34 minutes from start) The designated user account is presented, and by selecting the Next > button at the bottom of the dialog box, the process will continue to configuring the basic options for this mailbox.

20 FEBRUARY 2008


17 Configuring Options: Alias, Mailbox Database, Managed Folder and ActiveSync Policies

(Approximately 35 minutes from start) The next screen presents options to present a unique alias for the mailbox (that must be unique throughout the Active Directory forest), the Mailbox Database to host the mailbox, managed folder and ActiveSync policies as well.

The alias, similar to the login name, should be in a consistent format with regular procedures in place for duplicate exceptions.

A Mailbox Database must also be selected (designating which database within the organization the mailbox will physically reside). This should again conform to the organization’s documented policy of provisioning, where mailbox databases are designated for service level agreements, geographical access, etc.

18 Selecting the Mailbox Database

(Approximately 37 minutes from start) The administrator must then browse the available mailbox databases and select the appropriate database for the account as determined in the provisioning methodology.

The administrator can then select OK and will be returned to the previous mailbox options screen, with the chosen Mailbox Database listed.

19 Selecting Managed Folder Mailbox Policy to be applied to the Mailbox

(Approximately 38 minutes from start) The third option on this mailbox options screen allows for a Managed Folder Mailbox Policy to be applied (which generally covers length of retention for certain folders and enforces content settings).

This would require the appropriate selection of the prepared Managed Folder Mailbox Policies available, again to be documented and consistently configured throughout the provisioning team.

20 FEBRUARY 2008


20 Selecting ActiveSync Mailbox Policy for Mailbox

(Approximately 40 minutes from start) The fourth option on this mailbox options screen allows for an ActiveSync Policy to be applied.

These policies would generally be preconfigured for varying roles within the organization, covering configuration of their Windows Mobile Devices, options allowed, attachment sizes, maximum inactivity lock times, and a number of other options for these devices.

Again, the appropriate policy should be document and consistently applied by provisioning staff to ensure the safeguards and corporate usage policies are enforced.

21 Reviewing and Revising the Mailbox Options

(Approximately 42 minutes from start) Upon completing the configuration of all of these settings and options, the user is presented the dialog box displaying the choices. At this point, the selections should be reviewed and revised if needed, and then selecting next will proceed to the final confirmation dialog shown below.

22 Confirming the New Mailbox Creation Request

(Approximately 44 minutes from start) A final confirmation dialog will be presented, where the basic information is provided; the administrator is given the final chance to cancel the provisioning and review the selections.

20 FEBRUARY 2008


23 Provisioning the Mailbox to the User Account

(Approximately 45 minutes from start) As the processing is started, the required steps are executed by the Exchange Management Console and any warnings or exceptions may throw informational dialogs. (In the example provided here, a warning that Outlook clients before Outlook 2007 SP2 may not support the enforcement of the Managed Folder Mailbox Policy).

24 Execution and Results of Provisioning Attempt

(Approximately 47 minutes from start) Assuming everything has gone as expected and the mailbox provisioning succeeded, the user will receive the final dialog reporting the status of all events and the time required to perform all of the required steps.

The mailbox has been provisioned to the user account with this step’s succeeded message and the account has been mail enabled..

20 FEBRUARY 2008


! Phase 3: Creating Blackberry Account for the User

The next phase is to create an account for the user within Blackberry Manager. This may be a process that is owned by another functional area within the organization (particularly in larger environments where Active Directory and Messaging Services may be divided), so there may be a required documentation, notification and handoff before the procedure may continue.

1 Accessing Blackberry Manager

(Approximately 55 minutes from start) This screen illustrates the launch of the Blackberry Manager, which is generally located on aBlackberry Enterprise Server, or a computer on which the Blackberry tools have been installed.

The administrator will need to access and login to the machine where the Blackberry Manager is installed, with access to an account that has rights to access the machine and utilize the software.

In many (particularly larger) organizations, this functional responsibility may exist outside of the Exchange or Active Directory group, and so a handoff of the procedure may be required.

2 Selecting the Add User function and selecting the account for BES Services

(Approximately 56minutes from start) The administrator would typically select the Add User hyperlink once within the console and they will be presented a search dialog for the Global Address List.

After searching for and locating the account, the administrator selects them and places them into the right list box.

20 FEBRUARY 2008


3 Configuring User within Blackberry

(Approximately 58 minutes from start) At this point, the account has been given a license within the Blackberry Manager. The account will be listed within the users for the server to which it has been assigned.

The administrator would then select the account. A number of configuration options are available by right-clicking the account and selecting any of the submenus; IT Policies and devices can be assigned, and many final configurations may be applied.

4 Set Activation Password for the Account within Blackberry Manager

(Approximately 60 minutes from start) The provisioning of the user will generally require setting an activation password (or generating one automatically).

At this point, the user account has finally been provisioned a licenses within Blackberry Enterprise Server.

20 FEBRUARY 2008


! Pros and Cons to the Traditional Approach (Using Native Tools)

PROs

! Granular access is available for account details through each phase. By using the Native Tools, most every aspect of establishing an account within the target environments is available to the provisioning staff.

! Less concern over the effectiveness of the tools and their provider(s). Native tools are generally provided by the supplying vendor of the target platform and work more closely with them; there is far less testing, adjustment of script content, version synchronization, script augmentation, third party tools evaluation or purchases involved.

CONs

! Process is too long (approximately 60 minutes with this example) and requires higher-level staff to ensure quality of process. Costs too much money and time for staff to execute the required procedures and diverts their attention away from their more critical IT functions. Documenting and managing the procedures and policies can be very time consuming.

! Odds of consistent provisioning throughout the organization are much smaller. The steps executed, and number of possible errors, are exponentially higher with this approach.

! Procedures and steps need to be carefully documented, trained on and managed. Any change to the procedure or the introduction of new steps (systems) requires close collaboration and coordinated documentation and launch. Introduction of new capabilities or steps (change management) may require training across the organization prior to any change execution.

! Grants access to tools for roles that generally should not be given access. There is an inherently large risk to security and consistent provisioning associated to the number of steps and tasks provisioning staff must become familiar with. Provisioning Staff can easily execute many destructive procedures within the tools they have access to.

! Very difficult to secure unrelated capabilities of the accounts and tools of the provisioning staff. Leaves security holes and it is difficult to diagnose where errors in procedures may have been performed.

! Difficult to evaluate or audit the provisioning procedures. Coordinating the logs and understanding which accounts performed which actions when is much more difficult, and the particular actions of each provisioning often are not included with the native tools’ logs.

! Frequent updates and service packs released for the platforms require continuous document updates of existing procedures and changes to the workflow. These required changes can be difficult to identify as the systems are updated.

! Provisioning that fails in any step is stuck “mid-stream” and more likely to produce orphaned accounts. The process is difficult to rollback to the beginning (unless precisely documented), or must continue at the exact point of exception. Requires close coordination of provisioning user and back-end system staff when exceptions occur, so that provisioning will complete as consistently and promptly as possible.

20 FEBRUARY 2008


Approach Using Third Party or In-House Scripts

Often larger organizations may resort to in-house scripts or third-party scripts to be utilized in the provisioning of users. These can be scripts executed from a command line, accessed via shortcuts, or managed through a web page. Often the scripts are segmented into the functions within larger organizations (AD script, Exchange script, BES script etc). Creating and managing the scripts can be a time consuming procedure, especially when attempting to cover a larger portfolio of services. This example will assume separate scripts have been created, managed, documented, and trained for, across the three areas covered here: AD, Exchange and Blackberry.

Scripting solutions can vary from simple command-line batch scripts with no interface, targeting individual architecture components to comprehensive, secure, robust scripts hosted under an interface with multiple services and capabilities rolled within. The more services and capabilities the script portfolio targets, the more complex training and management of the tools becomes. As more services are incorporated and possible exceptions are introduced, more and more time is required to invest into the management, testing, documentation and distribution of the solution(s). The procedure is very dependent on the quality of the scripts provided: capabilities of diagnosing exceptions, rolling back operations, and providing for exceptions to default profiles are dependent on the developer’s skills and their time invested.

! Preliminary Phase: Creating, Testing and Modifying the Scripts

Creating and Distributing Scripts (Must occur prior to testing, documentation and launch of provisioning scripts. Initial deployment time: 60-300 hours) Specialized scripts will need to be designed, tested and documented per the environment’s requirements. The development requirements can be extensive and there are many dependencies to consider when designing, testing, documenting and releasing them:

! Scripts will need to be written for each of the functional areas, or an all-inclusive script will need to be provided that incorporates the various elements of AD, Exchange, Blackberry and other applications.

! The language, APIs and script providers may determine the language(s) and segmentation that the scripts may need to incorporate. Various departments may resort to different scripting solutions that support their respective applications.

! A coordinated testing, training, communication, distribution and change management procedure will be required to carry out each release and improvement to the script infrastructure.

! The languages, accounts used, system interoperability, and support roles will have to be predetermined in order for the scripts to be functional and be provided continued support.

! Exception handling and consistent logging will need to be thought out and documented thoroughly; any exceptions will need to be handled with appropriate messages and notifications to the process stakeholders.

! Support for the scripts will need to be broad enough to handle support, particularly where turnover or responsibility changes relocate the scripts’ ownership.

20 FEBRUARY 2008


"

20 FEBRUARY 2008


! Phase 1: Utilizing the Active Directory Provisioning Scripts

1 Accessing the Machine and Account(s) Utilized for Active Directory Provisioning

(Approximately 1 minute from start) The system that retains the scripts will need to be accessed, either physically or through remote tools, using an account that is provided this particular script’s functionality.

This will also require referencing the documentation on script usage and proper methodologies for this phase of the provisioning.

The Active Directory functional area may be presided over by IT, but in many larger organizations, these functions may have stakeholders who control and maintain ownership of these services. (This would require their involvement and a common workflow understood by all provisioning participants.)

2 Provisioning the Account into Active Directory Using the Active Directory Script(s)

(Approximately 4 minutes from start) The Active Directory script will need to be accessed per the documented usage for this portion of the scripted provisioning. This generally involves particular machines to be accessed or scripts to be acquired in order for the process to be started.

The scripts may be broken out into site-specific or employee role-specific versions, or appropriate measures would need to be understood to leverage scripts that have been distributed to a variety of machines (and customized for each site or provisioned role).

The script will need to be executed with the appropriate arguments and sequence as defined within the provisioning procedure documentation.

Any errors will have to be thoroughly diagnosed, and will generally require the involvement of the script writers and back-end IT staff to assist with process recovery.

Documentation would have to be generated and provided to the appropriate stakeholders for the next phase of provisioning.

! Phase 2: Utilizing the Exchange Provisioning Scripts

3 Accessing the Machine and Account(s) Utilized for Exchange Provisioning

(Approximately 7 minutes from start) The system that retains the Exchange service scripts will need to be accessed, either physically or through remote tools, using an account that is provided this particular script’s functionality.

This again will also require referencing the documentation on script usage and proper methodologies for this phase of the provisioning.

The Exchange and Messaging functional area may be presided over by IT, but in many larger organizations, these functions may have stakeholders who control and maintain ownership of these services. (This would require their involvement and a common workflow understood by all provisioning participants.)

20 FEBRUARY 2008


4 Utilizing the Provided Script(s) to Provision the Account a Mail Box (Approximately 12 minutes from start) In many (particularly larger) organizations, this functional responsibility may exist outside of the Active Directory group, and so a handoff of the procedure may be required.

The scripts written to support the Exchange infrastructure will now be called upon to allocate a mailbox to the account created above. This will often involve accessing the appropriate system(s) with the appropriate credentials.

This will require determination of what script to run considering the role of the account, the location of the account, and any derivative support scripts or script arguments that support all of the organization’s service offerings and account profiles.

Once determined, the appropriate script is executed and again, the provisioning user is dependent on the script’s successful execution, or the developers and back-end support staff may need to become involved in order for the process to complete as intended.

Phase 3: Utilizing the Blackberry Provisioning Scripts

5 Accessing the Machine and Account(s) Utilized for Blackberry Provisioning (Approximately 20 minutes from start)

The system that provides Blackberry script support will need to be accessed, either physically or through remote tools, using an account that is also permissioned for the Blackberry script’s functionality.

This will also require referencing the documentation on script usage and proper methodologies for this phase of the provisioning.

The Active Directory functional area may be presided over by IT, but in many larger organizations, these functions may have stakeholders who control and maintain ownership of these services. (This would require their involvement and a common workflow understood by all provisioning participants.)

6 Utilizing the Provided Script(s) to Provision the Account a MailBox (Approximately 28 minutes from start) In many (particularly larger) organizations, this functional responsibility may exist outside of the Active Directory group, and so a handoff of the procedure may be required.

The scripts utilized for provisioning Blackberry services for user accounts now come into play, and must be accessed using an account with appropriate credentials.

Again, the scripts may be divided or configured with options supporting the various locations and roles for which the Blackberry Service is provided.

Using the documented procedures, the administrator will call the scripts and carefully monitor the results, as exceptions may again require assistance from, and notifications to, external groups that must assist with the process completion.

20 FEBRUARY 2008


! Pros and Cons to the Approach: Using Third Party or In-house Scripting Resources

PROs

! Far less time is required to effect a provisioning. (But the initial investment in providing script components to support the broadening number of applications can be substantial.)

! Logs can be developed and maintained for the various steps (or a general log for all procedures can be created).

! There is far more control in what a user is allowed to effect during the use of these scripts. (The script will only access and modify that which they have been programmed to use.)

! New services and configurations can be provided for once internal staff can incorporate the systems, APIs and availability. (Although this means continuous management and release of script versions, which can result in modification and retraining of the provisioning methodology.)

CONs

! There is a large investment of IT staff time in developing scripts to provision the various components within the organization, and these scripts, their usage and proper sequence, must be thoroughly documented and trained on.

! The scripts (and resultant provisioning procedure) are only as good as the script writers’ capabilities, the APIs that they are working with, and time invested into robust error handling, logging and interface design. This can be a strain on several key IT resources.

! The provisioning scripts must be meticulously maintained and documented. As potential errors are uncovered and services are acquired/incorporated to the procedure, the scripts must be brought up to date, tested, re-documented, trained on, and distributed with change management coordination.

! Generally, only a few individuals within the organization are capable of diagnosing, upgrading and managing the scripts utilized. Affording the turnover of these staff and dedicating their time towards scripting of account creation generally is not an effective use of their time and skills.

! The targeting of scripts toward particular APIs and platforms result in specialists providing scripts for particular segments of the provisioning procedure, or the utilization of staff who have expertise in all areas of the provisioning (which generally can only be provided by “veteran” staff). Coordination of the script owners and stakeholders can be problematic. The procedure steps can seem inconsistent and incongruent in implementation (as the administrator incorporates various scripts covering various pieces of the account provisioning workflow).

! Scripts need to be quickly adapted as service packs, upgrades, API changes, or internal policy changes require adjustment of their capabilities and scope. Invariably, this leads to changes to the provisioning workflow, which require documentation, training and change management to be coordinated continuously.

! It is very problematic to diagnose problems and exceptions that may arise through the provisioning procedure, and generally will require intervention/coordination of back-end staff with the script writers to know how exactly to roll back (or continue to end) a failed provisioning activity.

20 FEBRUARY 2008


! Scripts (or the core script capabilities) must be configured and maintained for various locations, roles and account exceptions that need to be provided for (resulting in a larger amount of managed code within, and increased dependency upon, the script infrastructure).

! These scripts, and the workflow encompassing them all, is brittle to start and increasingly fragile as more and more services, roles, capabilities and functions are rolled into them.

20 FEBRUARY 2008


Approach Using Ensim Unify Enterprise Edition

Ensim’s product Unify Enterprise Edition v1.5 will be used as a demonstration of provisioning using a control panel (or web-based portal). The product is freely available for download from http://www.download.com, is under 100MB, and can be installed unobtrusively on practically any member server.

The control panel software allows the IT staff to utilize a web-based portal to provision accounts across the various services within the environment through web services. Access to the Active Directory and various server components is secured through the control panel. Granular role definition and rights enablement provide the administrator an easily securable platform that provides services from IT Administrative Staff all the way through to the end user.

The primary benefit of this approach is the provisioning automation and extensibility this architecture affords. Connectors for various services and applications can easily be acquired or created and placed into the package, and there is very little change to the provisioning procedure. Existing templates are easily configured to include the new service(s) and their appropriate configuration. There are also a number of benefits provided through the solution, including end user self service, that IT will benefit from upon installation.

! Preliminary Phase: Deploying the Control Panel and configuring Templates for Options

Installing the Control Panel

Setting up the Control Panel & Templates for Provisioning (Initial deployment time: under 1 hour) The Unify Enterprise product is installed onto any member server after downloading the less than 100MB installation package.

It does not change the Active Directory schema in any manner, and can be easily removed (and reinstalled) from the environment.

This provides an internal web portal (that could be tied into the intranet) for everybody from the System Administrator down to the end user to manage their services and messaging configurations.

System Administrators can then also delegate or withdraw capabilities to various roles within the organization, including the employee, where users are empowered with self-service for the most common help desk requests.

20 FEBRUARY 2008

http://www.download.com/


Configuring Templates: Defining the Roles and Service Configuration for Account Types

Creating Templates for each Account Type Templates retain the service configuration and Active Directory assignments that are common to particular roles within the company.

The templates can be created for the various account types within the environment, with available services preconfigured by the organization’s functional experts or provisioning policy manager.

The templates afford the provisioning process a consistent configuration per account and an unvarying provisioning procedure. As new services are introduced, they are easily added to the templates.

Generally, upon installation, templates would be created for the most common account configurations. By having the functional expert or provisioning process stakeholders review and configure templates, accounts are consistently given the proper configuration no matter who performs the provisioning (and the provisioning staff require no more expertise than how to use the control panel).

! Phase 1: Provisioning an Account using the Control Panel

1 Accessing the web portal

(Approximately 1 minute from start) The provisioning administrator would login to the control panel software using their own account. The control panel software can be accessed from any browser, anywhere (through VPN or by providing access to it through the firewall).

The solution also provides end user password resets through this page by asking a series of challenge questions to verify identity (so all roles benefit from self service password resets the portal provides).

2 Starting the Provisioning

(Approximately 2 minutes from start) The provisioning administrator is then presented their interface as configured by the systems administrator (only certain capabilities are provided as per the rights delegation that is configured within the control panel).

The administrator will simply select the Add User icon.

20 FEBRUARY 2008


3 Starting the Provisioning

(Approximately 2 minutes from start) The provisioning administrator is then provided the option to add one new user, connect to an existing user, or bulk load users from CSV file(s).

The administrator will simply select the Add one new user icon.

4 Configuring the account

(Approximately 2 minutes from start) The provisioning administrator then selects the template that has been prepared for the intended role, and provides the name and password information.

By utilizing the template, the configuration of services, applications, AD security groups, distribution lists and a myriad of options come predefined and do not need to be reviewed. The account will be consistently provisioned as intended, even as new services are introduced, transparently to the provisioning administrator.

The account profile path can also be set, and a home directory (with default drive letter) provided. Custom Active Directory schema extensions can also be configured per the environment’s requirements.

Once the template, name and password have been entered, the Administrator proceeds to then next screen.

5 Review of Security Groups and Distribution List Assignments

(Approximately 3 minutes from start) The next screen discloses the security groups and distribution lists that will be assigned to the account. (These are for review only, as the templates provide the default memberships required for the identified account types.)

The provisioning administrator simply selects the Next button.

20 FEBRUARY 2008


6 Confirming Provided Services

(Approximately 3 minutes from start) The next screen displays the services for which the account has been configured through the template. While the services can be modified, the templates offer the default service selections and configuration options for the account type; the provisioning administrator will simply select Next.

7 Confirming Provided Services

(Approximately 4 minutes from start) The next screen offers a chance to reconfigure services beyond the default defined within the account template.

Each service component can be finitely configured if there are exceptions to the template, or the template’s suggested service configuration reviewed. Pools can also be selected for geographic or service level considerations.

The provisioning administrator will simply select Next.

8 Final Account Review and Confirmation

(Approximately 5 minutes from start) The provisioning administrator will finally be presented with a summary page confirming the account and service configuration.

All aspects of the user account service portfolio and application configurations are presented in one screen for review. Because Unify Enterprise is tailored to work with the various applications, and the functional area owners assist with the template configuration, there is one place to look for all of the options and “best practice” configurations emplaced by the organization.

The administrator would select Next to begin the actual provisioning.

20 FEBRUARY 2008


9 Provisioning Completion (Approximately 7 minutes from start) The system will kick off an asynchronous execution of the provisioning request, and complete with a summary of all of the activities and duration or various steps involved the the account creation. The entire activity, and every associated sub task, is logged within the control panel logs.

Transparently to the provisioning administrator, the system will create the Active Directory account and kick off a series of web services calls to all of the servers and components involved in the service portfolio.

The transaction will be fully rolled back in the case of an exception at any point through the provisioning. This ensures that unless all of the steps and configurations occur without error, the procedure is entirely rolled back to the starting point. This results in no orphan accounts or provisioning requests that are held up midstream (and thus must be continued from the point of exception).

This completes the provisioning of the account through the Unify solution, utilizing the services portfolio and configuration provided by the template.

! Pros and Cons to the Approach: Using Ensim Unify Enterprise Edition

PROs

! Far less time is required to effect a provisioning. (Approximately 7 minutes with this example.)

! Templates allow the subject matter experts (or functional area owners) to preconfigure the services and configurations provided for the various account types supported. The templates allow for a consistent provisioning methodology, even disparate services and applications are introduced to the environment. The provisioning procedure will change very little, if at all, as new components are upgraded or brought online.

! Exceptions can be easily provided for through the use of templates and then direct modification of the required changes within the same interface.

! No native tools, account privileges or destructive capabilities are exposed to the provisioning staff. The rights delegation and role definition provided within the same interface allow system administrators to delegate or withdraw functional abilities as deemed appropriate.

! The provider for the major service connectors provides the development, testing and support for the various services and applications. Internal staff time does not have to be dedicated toward managing an internal script repository, and the skills required in introducing new applications to the management and provisioning are minimal.

! One-stop-shopping. System administrators all the way down to end users use the same web interface to administer the environment (or their own services). The SDK and web services architecture provide an open platform to connect to any application, regardless of operating system, through API calls.

! Easily deployed and the service connectors are provided fully tested and compatible with assorted applications and their various releases. No internal investment in developing scripts or allocating IT staff time to the provisioning components.

CONs

20 FEBRUARY 2008


! There may be some aspects of the environment and its applications that would have to be managed through native tools, or requested service connector enhancements. (example: Terminal Services security options)

20 FEBRUARY 2008

ORGANIZATIONAL USER PROVISIONING: COMPARISON OF COMMON METHODOLOGIES 28 20 FEBRUARY 2008


Legal and copyright notice

This document contains information proprietary to Ensim Corporation and its receipt or possession does not convey any rights to reproduce, disclose, manufacture, or sell anything it might describe. Reproduction, disclosure, or use without Ensim’s specific written authorization is strictly forbidden. Ensim Corporation makes no representations or warranties with respect to the contents or use of this document. It also reserves the right to revise this publication and make changes to the content at any time, without the obligation to notify any person or entity of such revisions or changes.

Further, Ensim Corporation assumes no responsibility or liability for any errors or inaccuracies, makes no warranty of any kind (express, implied or statutory) with respect to the contents or use of the information, and expressly disclaims any and all warranties of merchantability, fitness for particular purposes, and non-infringement of third party rights.

Ensim and the Ensim logo are registered trademarks of Ensim Corporation. All other trademarks are the property of their respective owners.

© 2007 Ensim Corporation. All rights reserved.

CORPORATE HEADQUARTERS

ENSIM CORPORATION 3945 Freedom Circle, Suite 1100 Santa Clara, California 95054 (408) 496-3700 www.ensim.com

20 FEBRUARY 2008

Documents

Organizational User Provisioning: Comparison of · PDF fileOrganizational User Provisioning: Comparison of Common Methodologies ... Blackberry Enterprise Server 4.1.4. ... For larger