User Provisioning, Comparison of Common Methodologies, Cloud Provisioning

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
20 FEBRUARY 2008

1

!

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

2

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

3 Creating the Password and Password Policies for the AD account
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

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

4

5 Assigning extended Active Directory information

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.

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

5

7 Designating User Profile Location, Login Script, Home Directory for the Account
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
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
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

6

10 Selecting the Dial-in, Remote Control and Terminal Services options for the account
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
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

7

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

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

8

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

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

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

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

9

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

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

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

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

10

20 Selecting ActiveSync Mailbox Policy for Mailbox

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

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

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

11

23 Provisioning the Mailbox to the User Account

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

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

12

! 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

13

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

14

! 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

15

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

16

"

20 FEBRUARY 2008

17

! Phase 1: Utilizing the Active Directory Provisioning Scripts

1 Accessing the Machine and Account(s) Utilized for Active Directory Provisioning
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)
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
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

18

4 Utilizing the Provided Script(s) to Provision the Account a Mail Box
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
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
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

19

! 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

20

!

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

21

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

22

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

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

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

23

3 Starting the Provisioning

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
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

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

24

6 Confirming Provided Services

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

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

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

25

9 Provisioning Completion
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

26

!

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

27

20 FEBRUARY 2008

28

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

29

User Provisioning, Comparison of Common Methodologies, Cloud Provisioning

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to User Provisioning, Comparison of Common Methodologies, Cloud Provisioning

Similar to User Provisioning, Comparison of Common Methodologies, Cloud Provisioning (20)

Recently uploaded

Recently uploaded (20)

User Provisioning, Comparison of Common Methodologies, Cloud Provisioning