Provisioning simply means adding users to a SIMS mail system. Having a plan for provisioning is particularly important before you install SIMS. SIMS includes a set of provisioning tools. These are:

SIMS Administration Console - A browser-based console for performing a variety of configuration and provisioning tasks.

Delegated Management Console - A browser-based console for adding, modifying and deleting users and groups. This tool is designed for local control of hosted domains.

SIMS Command Line Utilities - Enables provisioning from a command line interface. You can do bulk loading with these utilities.

NIS/NIS+ Bulk Loading Scripts - Bulk load and synchronize users/groups with a NIS/NIS+ database using a set of custom-designed scripts and processes. Refer to the sections on populating the directory in the SIMS System Administration Guide.

SIMS Provisioning Guide - This book, which explains how to create LDIF records for performing common provisioning tasks.

You will use tools appropraite for your particular situation. This guide is targeted for those sites where the primary repository of subscriber information is something other than SIMS LDAP directory. The guide provides the detailed information about how users/domains/groups are provisioned in SIMS LDAP directory. We expect this information to be used by sites in developing custom provisioning tools to keep the data in their order entry system and SIMS LDAP directory synchronized.

For example, a site may have an order entry system based on an existing database. You will need to plan for adding users/domains/groups currently in the database to SIMS and also take changes to the order entry database and reflect those changes in SIMS LDAP directory.

Setting Up an Internet-Style DC Tree

SIMS supports the Sun Directory Service and the Netscape Directory Service. The directory service supports the storage and retrieval of data in the SIMS messaging system, including user profiles, distribution lists, access control meta-data, and configuration attributes of services.

FIGURE  1-1 Directory Information Tree Example.

Data in a DC Tree Model

Data is stored in the directory as directory entries, which consist of object classes and the required/optional attributes of those object classes. Thus, an e-mail user is represented in the directory by an entry which stores information about that user. One of an entry's object classes are structural, that is, an object class that determines the entry type and which cannot be changed. The other object classes are called auxiliary object classes, and may be added or deleted to define additional services to an entry.

Directory entries are identified by a unique name, called a distinguished name (DN). The DN is the unique entry that shows the entries location in the DC tree. This tree model is similar to that of most file systems. The root node of the tree is represented by o=internet.

The second-level nodes below the root correspond to the top-level domains in the DNS namespace. In the example above, the DN for the top-level domains have the following suffixes:

dc=com, o=internet

dc=edu, o=internet

The structure of the DN includes a relative distinguished name (RDN). The RDN is the left-most attribute data pair in the DN. The RDN must be a unique value, so you avoid collisions of multiple entries with the same DN. Remember, each DN must be unique, and each RDN must be unique also.

Each successive attribute value pair following the RDN is the RDN of the next parent branch node in the tree hierarchy. The final, right-most attribute value pair represents the conceptual root point of the DIT. The entire string is referred to as the suffix. The RDN is shown in a suffix string with the format cn= xx, where cn is the common name.

The hosted domain or organization nodes below the top-level domain nodes are required to have the following organizational containers:

ou=people - contains user entries for the hosted domain

ou=groups - contains the distribution list entries for the hosted domain

ou=services - contains the service state entries for the hosted domain

LDIF Notes

LDIF (LDAP Data Interchange Format) is the standard text-based format for describing directory data. It is used when exporting data from and importing data to the LDAP directory server. We recommend purchasing a good book on LDAP programming to use the manual most effectively. Here are some other LDIF notes:

Capitalization is not significant in LDIF records, hence inetMailGroupStatus is the same as inetmailgroupstatus. In this book we generally use capitalization to make attributes more readable.

The order of LDIF statements in a record after the DN is not significant. That is, the distinguished name (DN) of the entry must be the first attribute-value pair in an LDIF record. After that, all other attribute-value pairs can appear in any order. For readability, the objectClass statements are often placed at the beginning, followed by the other attribute-value pairs.

If an attribute line is more than one line, it must start with a blank space.

If multiple records are described in a file, a blank line is required between each record.

Location of LDAP commands for the Sun Directory Server: /opt/SUNWconn/bin/

Format of LDIF record for adding an entry (ldapadd()): dn: <dn of entry to be added> changetype: add <attribute type>: value ...

Format of LDIF record for deleting an entry (ldapdelete()): dn: <dn of entry to be deleted> changetype: delete

Format of LDIF record for modifying an entry (ldapmodify()): dn: <dn of entry to be modified> changetype: modify <modify type> <attribute type> <attribute type>: value - ...

ldapmodify() example format:

Searching for and viewing an entry using ldapsearch() example: