Enterprise Provisioning
Here we describe some of the challenges related to provisioning, discuss the solutions and after looking into server side requirement briefly, continue to some tried-out provisioning strategies. We do not yet offer turnkey solutions or program code, excluding some snippets in the Appendix.
Contents |
[edit] Acronyms and definitions
- Enterprise User Configuration File: EUF. A container for user-specific and enterprise-specific configuration values collected from various sources.
- Enterprise Package: EP. It contains the Enterprise Configurator and also contains a reference to all other required packages.
- Enterprise Configurator: Part of the EP. It is an application which reads the EUF and applies the configuration values into device and applications configuration.
- Content Type definitions: Using different Content Type definitions, the web browser can be made to either prompt the user to save a file or invoke the Application Manager. See the Appendix for more details about Content Type definitions.
- Device: The user device that is being configured.
[edit] The Provisioning Process
[edit] The wireless challenge
Accessing a company network usually requires some keys that are available only inside the network to be accessed.
For illustration, picture a man standing at the courtyard of a house. Inside the house, all room doors are locked. In a hallway there is a strongbox with a combination lock. Inside strongbox are keys to all room doors. The man knows the strongbox lock combination. The only problem is that the front the door of the house is locked as well and the man does not have the key. The front door key is in the strongbox. This is roughly equal with the starting point of provisioning a wireless device.
[edit] Additional challenges
In addition to general problem, there is a set of features which create more challenges for the provisioning process. These include:
- Currently, the device ships without any kind of enterprise configurator or pre-configurator.
- The device is unable to handle SMS configuration messages.
- Application Manager has, in the default configuration, repositories which are located in the public Internet. If these repositories are not accessible from the network the device is connected to, the Application Manager halts completely for extremely long periods (around 30 minutes). We call this as "the Application Manager halting problem".
The main source of these challenges is the consumer-oriented factory set-up of the (N-series) devices. Future firmware/software upgrades might address some of these issues.
[edit] Provisioning phases
[edit] Enrollment
Purpose of the enrollment phase is to
- Overcome the wireless challenge by creating a controlled way to create and deliver the EUF.
- Create the EUF which consists only of the required information.
- Store the EUF securely to be used by subsequent phases.
- Initiate the bootstrapping phase.
In this document, we distinguish between two kinds of enrollment:
- direct: The user performs it by using the device itself.
- indirect: The user performs it by using some other method, for example, a desktop computer.
[edit] Bootstrapping
Purpose of the bootstrapping phase is to
- Connect the device to the Installation Server.
- Possibly, retrieve the EUF and store it on the device.
- Invoke the Application Manager for performing the installation phase.
In most cases, there are two alternative ways to deliver the EUF:
- Via file
- Easy-to-implement
- Deliver EUF as a file to be saved by the Web Browser
- Deliver EP install file to invoke Application Manager
- See Appendix for required content headers
- Via package
- Easy-to-use
- Create a package on-the-fly that contains the EUF and includes EP as a dependency
- Create a temporary repository and an install file for the package
- Deliver the created install file to invoke the Application Manager
- See Appendix for further instructions
[edit] Installation
Purpose of the installation phase is to
- Retrieve the EP and install it.
- Retrieve other application packages and install them.
- Execute Enterprise Configurator to apply the configurations on the device.
[edit] Server setup
[edit] Server roles
For provisioning, three kinds of server roles are required. Each role may have their own server, all roles may be executed in one server, or anything in between.
- Installation server: User devices download application packages from this server.
- Enrollment server: User devices contact this server to prove their identity and generate the EUF.
- Admin server:
- The server which uploads packages to provisioning server
- Likely acts also as development/build server
[edit] Minimal requirements
Enterprise application suite as such does not set requirements for the server hardware or operating system. Minimum functional requirements are:
- Installation Server
- Few gigabytes of storage space (current release takes roughly half gigabyte)
- A web server running at port 443 (http over SSL)
- Ability to run in-house server end applications of technology choice of the enterprise
- Enrollment Server
- Access to Enterpise User Databases
- Access to upload data to provisioning server
- Admin Server
- Access to upload data to provisioning server
However, in order to keep things simple it is strongly advised to follow the recommendations below.
[edit] Practical recommendations
Hardware requirements are fairly modest (it would take quite many of these tiny devices to overload a server)
- Entry level server hardware
- 10 GB or more storage space
- High availability and backup arrangements according enterprise policies
- Criticality note: Provisioning service being down does not prevent use of the devices, only installations and updates
The recommended operating system is Linux (e.g., a server-oriented distribution).
- Install minimal set of packages
- SELinux is recommended to be turned on (enforcing) for all servers located outside corporate firewalls
The following table defines the recommended applications for each server role:
Application | Installation | Enrollment | Admin |
---|---|---|---|
Apache web server | yes | yes | no |
CGI support | yes | yes | no |
SSL support | yes | yes | no |
Python | yes | yes | no |
python-ldap | no | yes | no |
python-cheetah | yes | yes | no |
OpenSSH client | no | yes | yes |
OpenSSH server | yes | no | no |
It is also recommended to purchase an SSL certificate for the provisioning server from a commercial CA, such as Verisign or Thawte. These certificates are readily installed on device. This removes one configuration step (accepting the certificate) from the device user. It also increases security (users usually blindly give approval to many questions during software installations).
[edit] Summary
As we can see, the requirements are quite similar to any Linux distribution mirror with added requirements to connectivity towards enterprise databases. Enabling the gathering of the necessary account information poses security considerations to the solution as well.
Now we can continue to learn about tried and tested provisioning strategies.