Provisioning
Once you know the system is installed and operational, the next major tasks is most likely how to best add and remove users, sometimes also called accounts or other terms. In the ISP world, the term used to describe this process is called provisioning. As with many things, there is often more than one way or method of provisioning accomplishing the task. Provisioning users or accounts is no different. Provisioning sometimes assumes starting a new user from scratch, but it may in fact be one of the steps in the migration process of an organization's older mail system. This chapter approaches it from the new user perspective, though the approach is not totally different when doing this as part of a migration. Some additional issues are discussed in Chapter 11, “Migration,” on page 167.”
Technically there may be many ways of provisioning, but there are really four main methods:
Web— delegated administration for messaging and collaboration or identity server
CLI— command-line interface for the iPlanet Directory Administrator
Ultimately, these methods (FIGURE 5-2) all interact with the Messaging server in two places—the directory server and the mailstore. One thing to note is that creating user information in the directory does not create the physical mailbox in the mailstore nor does creating the mailbox (folder) in the mailstore create the user information in the directory. The tricky part is creating the user information in the directory with the appropriate attributes (fields) and having the users authenticate with the messaging system.
Figure 5-2. Administration Interfaces Architecture Overview
The following sections examine each of the four provisioning methods and outline some of the pros and cons of each method.
Administration Console
The Sun ONE Administration Console is a Java program that can be executed locally on the mail system or in a distributed (remote) fashion on any system supporting the Java™ Runtime Environment (JRE) 1.1.8. It connects to an administration process (daemon) through HTTP or HTTPS. The administration console provides a very low level access to most parts of the message system, including the Messaging Server, Directory Server, and Web Server. This access includes configuration data, user data, log data, and so forth. As such, it is primarily used for configuration and debugging purposes, not as a day-to-day way of administering the system.
Note
Occasionally problems exist when starting the Messaging Server Administration Console and remotely displaying the results. The splash logo can block the login entry box. To work around this issue you can start the Messaging Server Administration Console without the splash graphic by using the command startconsole -x nologo.
While it is possible to add users or change user information by using the administration console, it is typically reserved for configuration and diagnostic functions by the highest- level administrators.
An example of an appropriate use would be to configure the messaging server to accept IMAP over SSL connections. An example of poor usage for the administration console would be to add twenty user accounts or even one user account for that matter.
Not customizable
You should equate the administration console to root or highest-level administration access, and as such it should be reserved for use by only those persons performing these duties on the messaging system.
Web
Another way to administer the Messaging System is via the Web. Actually, there are two ways to use the Web to administer the system—the Administration Web Interface and the Delegated Administrator for Messaging. The two methods are very different.
The Administration Web Interface provides basic administration function access such as starting, stopping, restarting, backing up, and restoration functions for some of the services of the Messaging Server. It is primarily designed for help desk personnel with minimum training and limited duties, as well as remote administration work when using the Java-based administration console is not possible.
The Delegated Administrator for Messaging (FIGURE 5-3)provides more user and domain management functionality for help desk and self-service end users. Functions for help desk personnel include adding, removing, and changing user information (if permitted). The functionality of the Delegated Administrator for Messaging can be restricted to provide specific help desk administrators for each domain within the messaging system as well as user administrators for each domain, which can ultimately reduce the burden of administration for the main administrators. For end users, this interface can be used to access functions such as mailing list management, vacation messages, mail filters, user information, and so forth, if permitted.
Figure 5-3. Delegated Administrator for Messaging
Overall these web interfaces are aimed at the help desk and end user population. They are not the fastest methods of administration, but they provide easy-to-use interfaces for occasional use. These interfaces can be customized because they are web pages (HTML, JavaScript™, and servlets) for your specific organization. So if you do not want people to be able to change their password or basic information via the Delegated Administrator interface, it can be modified to remove these options.
Command-Line Interface
The functions to provision users and mail accounts in the Messaging Server are available from the command-line interface (CLI). This interface provides the ability to automate and program (script) your organization's business rules regarding user and mail account provisioning.
Note
The command line interface is really an interface into the Delegated Administrator, not directly into the Directory Server or the Messaging Server. You may see the terms CLI, Netscape delegated administrator (NDA) CLI, and IPlanet delegated administrator (IDA) CLI used interchangeably in this section.
This low-level interface is not designed for end users at all, and is typically reserved for the highest level of administrators or for help desk personnel via automation (scripts) only. It is very possible to add and delete thousands of users or accounts in minutes by using the CLI. It has the capabilities to quickly add and delete or otherwise mess up the Messaging Server, so treat it as you would root access on the server. This includes security issues such as ensuring to install the production server with appropriate users and groups as well as applying other security precautions.
Another use of the CLI is to perform debugging and diagnostic work. There are several commands as well as options that provide the ability to trace email paths and routing and look at the functioning of the various daemons. For more information, see Chapter 14 of the iPlanet Messaging Server Administrators Guide or go to:
http://docs.sun.com/source/816-6009-10/trblesho.htm#13833.
Code Example 5-3. Sample CLI Showing Creation of "testuser" Account
root@sparc5-1:/A1000/demo6789/ims52/ndacli/bin> ./imadmin user create -l testuser -W |
Overall, the command-line interface provides the one of the best ways to automate and perform bulk adds, deletes, and modifications quickly, plus implement an organization's policy regarding messaging.
Lightweight Directory Access Protocol
Ultimately, everything—the administration console, the web interfaces, and the CLI—interacts with the directory in some manner. So performing provisioning work by interacting with the directory by using the LDAP is not only possible, but very much like the NDA CLI in terms of capabilities.
Direct interaction using LDAP provides most of the benefits of the CLI without access to the very low level utilities and commands. It is also one of the best ways to automate and perform bulk adds, deletes, and modifications along with the CLI. And, just like the CLI, it can be used to enforce and implement an organization's policy regarding messaging. Direct interaction with the LDAP directory and its contents also means additional security precautions are necessary. Direct manipulation or access should be reserved for the highest- level administrators. Access for help desk personnel or lower-level administrators should be done only through scripts or other methods that can add additional checking and precautions. For more information see Chapter 10, “Security,” on page 153.”
Access to functions— not as low level as the CLI, but still for scripts and senior administrators only
Very customizable
User Commands ldapmodify(1) NAME ldapmodify, ldapadd - ldap entry addition and modification tools SYNOPSIS ldapmodify [ -a ] [ -b ] [ -c ] [ -r ] [ -n ] [ -v ] [-F ] [ -d debuglevel ] [ -D binddn ] [ -w passwd ] [-h ldaphost ] [ -M authentication ] [ -p ldapport ] [-f file ] [ -l nb-ldap-connections ] /opt/SUNWconn/ldap/bin/ldapadd [ -b ] [ -c ] [ -n ] [ -v ] [ -F ] [ -d debuglevel ] [ -D binddn ] [ -w passwd ] [ -h ldaphost ] [ -p ldapport ] [ -f file ] [ -l nb-ldap-connections ] DESCRIPTION ldapmodify opens a connection to an LDAP server, binds, and modifies or adds entries. Theentry information is read from standard input or from file, specified using the -f option.
Code Example 5-4. Sample Template
dn: uid=<uid>, ou=people, o=<hostname_fqdn>, o=isp objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetUser objectClass: ipUser objectClass: nsManagedPerson objectClass: userPresenceProfile objectClass: inetMailUser objectClass: inetLocalMailRecipient mail: <uid>@<hostname_fqdn> mailUserStatus: active dataSource: NDA 4.5 Delegated Administrator mailHost: <hostname_fqdn> givenName: History cn: <first_name> <last_name> uid: <uid> sn: <last_name> mailDeliveryOption: mailbox inetUserStatus: active userPassword: <password> creatorsName: uid=serviceadmin,ou=people,o=<hostname_fqdn>,o=isp modifiersName: uid=msg-admin-<hostname_fqdn>-20020710153937,ou=people ,o=<hostname_fqdn>, o=isp createTimestamp: 20030414044513Z modifyTimestamp: 20030414051012Z nsUniqueId: d5cba701-1dd111b2-80cac302-81db34e7 nswmExtendedUserPrefs: meDraftFolder=Drafts nswmExtendedUserPrefs: meSentFolder=Sent nswmExtendedUserPrefs: meTrashFolder=Trash nswmExtendedUserPrefs: meInitialized=true pabURI: ldap://<hostname_fqdn>:389/ou=<uid>, ou=people, o=<hostname_fqdn>, o=isp,o=pab |
Methods Analysis
After discussing the four methods of provisioning at a high level, the question “What is the one way to do provisioning?” still remains. The answer is that it depends on the specific needs of your organization, including the end users, the administration staff, and the organization as a whole. Several factors, including which features such as vacation message or mailing list, may require the use of the Delegated Administrator for Messaging interface to some degree. Other factors include account turnover, skills of the administration staff, organizational policies, and so forth.
As a general rule, the best practices are:
Administrators console
Top administrators only—for configuration
Diagnostics and tuning only
Web
Help desk and end-user self service
Customize or write your own scripts. Use those provided as examples.
Exceptions to bulk add and delete scripts. (There will always be exceptions.)
Main provisioning interface for small organizations or others with minimal account additions and deletions—approximately one addition and deletion per day. (3,000 accounts with a one-percent change per year equals 300 accounts added or deleted per year.)
CLI/LDAP
Automate as much as possible.
Should handle 99+ percent of the work
Exceptions handled by web or help desk personnel. (There will always be exceptions.)
Issues
There are many issues beyond which method is best or which method to use for provisioning. The remainder of this chapter uses the example of a university trying to automate their provisioning of the messaging system. Once automation has been decided upon, the most significant issues are:
Authoritative Sources
Data Feeds
User ID
Each of these issues must be addressed and documented for the smooth provisioning of the messaging system. The following sections examine each of these issues in more detail and provide an example scripts to show how this all comes together.
Authoritative Sources
When provisioning users or accounts, some basic information is required—at a minimum, user ID, password, and email address to be used. The Messaging Server includes a directory server, so many organizations also use this to provide basic directory services to various LDAP-enabled applications such as Microsoft Outlook or Netscape Communicator. Realistically, you may want more information, such as full name and a phone number.
So, what is an authoritative source? An authoritative source is a source where the information or data is known to be accurate and up to date, and is most likely located where the information originates within the organization. In some cases it is not possible to integrate directly with the original source, but if something contains the same information and is as up to date, it can be said to be authoritative too. Simply put, information or data just does not suddenly appear from thin air; rather, it is the end result of a business process or part of a business process. A good example is the human resources (HR) system within an organization as an authoritative source on employees. Since you must go through the various HR processes and procedures to be an employee, it is highly likely that the HR system (database) is an authoritative source for employee information. Why? Legal and regulatory requirements as well as accounting (payroll). So it is pretty safe to say that a person who is not in the HR database is not an employee. Is this always true? No, but it does address at least 99 percent of the cases.
Regardless, think of this as a business workflow exercise, and ask the question “How does the organization get someone's identity, be they an employee, contractor, or whatever, before providing network or computing access?” Is it simply a matter of an email coming from a manager, or is it more formal, requiring that the person be in the payroll system too?
Typical authoritative sources might be:
Human resource system (HRS)
Student information system (SIS)
Directory Server database
Information systems database
Contractor/vendor database
Visiting guest database
In some organizations, there may actually be multiple sources from which information is available. Which source is valid depends upon a person's function or duties. Depending upon security requirements, you may also be required to check multiple sources to ensure that the person appears in all of them.
Data Feeds
Now that the authoritative data sources and their owners have been identified, the next issue faced when automating the provision process either via the CLI or direct LDAP integration is getting the data from the authoritative data sources. This requires input and agreement from the authoritative data source owners.
In a few situations, these authoritative systems or data sources can be directly integrated with the Messaging Server's directory via LDAP, to automatically provision accounts when new users are added to the payroll system or delete them when they are removed from the system. This requires some scripting or configuration on the authoritative source application. An example of this might be PeopleSoft 8's LDAP integration capabilities. However, in most organizations these data sources are not generally accessible, and so direct data extracts or integration is not possible.
Typically, though, there is a separation between the groups who control these systems and the group that administrates the messaging system. So many times tying the systems together directly is just not practical or possible. In these situations, the most practical integration is through a comma delimited file format sometimes referred to as a comma separated variable-length (CSV) file. Then, what information is needed and how this file is to be obtained and transferred and how often must be determined.
This file contains the information necessary to create the messaging account. It also typically contains a flag to indicate the action to be taken, whether this is a new account (add), or an existing account requiring deletion (delete) or updating (modify). There are also two other types of actions possible with the Messaging Server—activate and deactivate. One of the features of the Messaging Server is the ability to deactivate an account or entire domain while maintaining all of its associated information, including passwords, forwarding, address book entries, and so forth. This is a very useful feature in the University setting, where the policy might be to cut off services such as email if accounts are in arrears until such time as parking tickets or library fines are paid. Using this feature, an organization can simply deactivate an account and then easily reactivate the account without causing significant amounts of work such as adding the entire account back into the system.
So, the action flag or field in the CSV file might contain something to indicate the following actions:
ADD
DELETE
MODIFY
ACTIVATE
DEACTIVATE
Our example uses the following designations to simplify this a bit, yet still represent all the actions:
ADD
DEL
MOD
ON
OFF
Generally the file contains the basic information needed to create the record, as stated previously, plus some other information desired to make the directory useful. Often it is not necessary to be too literal, as some information or fields can be derived many times. An example might be full name where it is really a combination of first and last name. Every organization and authoritative data source is different, though. One thing to look for when using multiple authoritative data sources is fields that are common between them. Use the same fields consistently across all the data sources, if possible.
Since the purpose of this process is to automate the provisioning, the simplest method that does not require human intervention seems to work the best. In many organizations this could be a shared file system or using something such as File Transfer Protocol (FTP). This method is something that is worked out between the authoritative data source owner and the messaging administration group.
How frequently provisioning is done depends upon several factors. How quickly do you need messaging provisioned? Is there adequate CPU power to generate the CSV file as frequently as needed or desired? Some organizations do this nightly so that all new messaging accounts are created sometime between 10 p.m. and 4 a.m. for example. Other organizations desire more frequent updates, thus generating and processing the CVS hourly. Some modification of the scheduling can be done once the basics are working. Perhaps the biggest issue in this area is managing the end-user expectations. Were they informed that email accounts are created twice daily, or are they under the assumption that this is done in real time? Sometimes this issue is influenced by existing policy, while other times new policies must be set.
One final issue to consider regarding schedule or frequency is that not all functions have the same requirements. For example, if the policy is that new accounts are created once daily sometime between 10 p.m. and 4 a.m., that does not mean modifications or deletions must wait 24 hours. In some organizations, policy dictates that account deletions must happen within a short period of time for security reasons. So a policy such as this might drive the scheduling to something shorter than once daily.
User ID
Now that the issues of authoritative data sources and data feeds have been addressed, the next issue in provisioning is the user ID and everything that surrounds it. In some ways this is more difficult than the other issues to address because it is more of a policy issue. In some cases, it is necessary to maintain (grandfather) an existing standard for user ID creation for existing users while implementing a new policy for all new users.
Some points to consider when addressing the user ID issue are:
This can be within the entire messaging system or within each domain, that is, acme.edu. However, if IDs are unique only within each domain, users will be required to log in with their user ID plus domain, for example, [email protected], whereas if user IDs are unique across the entire messaging system users can log in using only their user ID, for example, jsmith. This can affect other issues, though.
How do you ensure uniqueness?
That can be difficult. Very few pieces of information about someone are completely unique. First name? No. Last name? No. First name plus last name? No. Social Security number? Pretty much, but there is a privacy issue.
One possible answer is to make the user ID a derivative of the unique field from the authoritative source. This could be based on the social security number or employee ID number, but not actually use the number itself. Perhaps the person's first and last initials plus employee ID number could be used.
Does not have to be tied to email address or name
One common misconception is that a user's email address and user ID are the same thing. This is not necessarily true. While the two are linked together, they do not have to contain even the remotely the same information. For example, the user ID could be a12345 while the email address associated with that could be [email protected]. The Messaging Server has the ability to assign multiple addresses to a single user ID. You must configure a primary email address at a minimum, but you can assign numerous alternate email addresses. So while user ID is a12345 and the primary email address is [email protected], it is quite possible to also assign [email protected], [email protected], and [email protected]. While there are other methods within the Messaging Server to do this, often a way to provide backward compatibility to older messaging environments is needed. An example might be that Acme University is consolidating two messaging servers into a single server. One was for faculty and staff ([email protected]) and one was for students ([email protected]). Using the alternate address capabilities, it is possible assign [email protected] as the primary email address and [email protected] as the alternate address, so that email sent to the old address still arrives in the user's inbox.
Organization's single sign on (SSO) strategy
Since one part of the system is an LDAP-compliant directory server, it can be leveraged as the beginning of an organization-wide directory and authentication server. In some organizations, efforts to consolidate sign on and authentication sources are already underway. In still others, consolidation is only a notion, and in others, it is not even being considered. Rather than implement a messaging system with one set of user IDs today, only to have to rename the user IDs a short time later, it might be good to figure out if there is an SSO strategy or project underway.
Goal and overall design of email system
There is a significant difference between an email system designed for an ISP and one designed for an enterprise. One goal in some organizations might be email address for life. This means that the user ID and primary email address can never be reused. This very close to the next and final issue.
Turnover (churn) in user population
As with phone companies or cell phone companies, churn or turnover in user population is a key factor in operations in several ways. For a messaging system, it is not only an issue regarding provisioning method determination (that is, web interface versus CLI batch) but also reuse and provisioning of user ID and email addresses. Consider whether or not your organization has a 25 percent change in user population each year. That means in four years almost every user ID and email address in the messaging system will no longer be valid. If you have a jsmith user ID that is [email protected] email address, how soon will it be before you reuse this address and user ID?