Documente Academic
Documente Profesional
Documente Cultură
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 ADs 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.
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 organizations 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
2
(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.
(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.
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 accounts 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 accounts 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.
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).
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.
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.
(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.
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 organizations documented policy of provisioning, where mailbox databases are designated for service level agreements, geographical access, etc.
(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.
(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.
10
(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.
(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.
(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.
11
(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).
(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 steps succeeded message and the account has been mail enabled..
12
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.
13
(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.
(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.
14
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.
15
! !
16
"
17
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 scripts 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.
18
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
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.
21
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 organizations 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).
(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).
(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.
23
(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.
(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.
24
(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.
(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 templates suggested service configuration reviewed. Pools can also be selected for geographic or service level considerations. The provisioning administrator will simply select Next.
(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.
25
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
ORGANIZATIONAL USER PROVISIONING: COMPARISON OF COMMON METHODOLOGIES 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)
27
28
ENSIM CORPORATION 3945 Freedom Circle, Suite 1100 Santa Clara, California 95054 (408) 496-3700 www.ensim.com
29