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
Provisioning 63 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: ■ User IDs must be unique.
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.