Quick Start

Appendix A
Quick Start

his appendix is intended for the administrator who wants to use the directory server to support basic SuiteSpot administration. You should read this appendix if the following describes you:

You just want to get some SuiteSpot server running, such as Enterprise, Messaging, or Collabra Server. That is, you are only using the directory server so that Netscape SuiteSpot servers have a place to store user and group information.

You are supporting employees that are close to one another within your network topology, and so network connections are not a major issue for you. That is, you are not trying to support employees across wide area networks, dial-up connections, or over unreliable network feeds between buildings.

You are supporting a relatively small number of entries (fewer than 10,000)

You do not want to develop a directory tree structure.

Fortunately, straight out of the box the directory server supports basic SuiteSpot activities. There are just a few things you need to consider before and during directory installation, and this appendix outlines those issues for you.

Note Make sure you have read Chapter 1, "Welcome to the Directory Server," before continuing with this appendix. Chapter 1 contains information about basic directory server concepts that you need to understand before performing server installation.

A Word of Advice

By following the directions in this appendix, you can rapidly deploy a simple directory service for use with SuiteSpot servers. This is appropriate for testing or review purposes, or even for installing servers into a production environment if that environment is controlled and relatively secure.

However, for most production directory deployments, the environment is not so idealized as is assumed by this appendix. For this reason, if you are installing your server outside of the lab environment, you are strongly recommended to at least examine the data planning issues discussed in Chapter 3, "Planning Your Directory Data," and the access-control issues raised in Chapter 5, "Planning Security Policies."

In general, if you are deploying your directory service into a production environment, taking an afternoon to become familiar with the concepts and issues raised in the earlier portions this manual will go a long way towards helping you build a robust, secure, easily-administered directory service.

Planning Your Suffix Value

Before you get started, you must plan the suffix name under which you are going to store your directory entries. If your enterprise already has an Internet domain name registered for it, then use a suffix value of the following format:

o=<your domain name>

That is, if your enterprise's Internet domain name is Airius.com, then use:

o=airius.com

as your suffix. If you do not have an Internet domain name registered for you enterprise, then simply use your company's name. For example:

o=airius corporation

Directory Tree Advice

Keep your directory tree as flat as possible. For a small or non-production directory service, there are no technical or administrative advantages to branching your directory tree. Consequently, simply create every entry at your directory's root level. That is, if your suffix is o=airius.com, then create all your entries using the following format:

uid=<some value>, o=airius.com

for people entries, and

cn=<some value>, o=airius.com

for group entries.

DN Advice

The one thing you absolutely must do is make sure every DN is unique. This can be one of the greatest challenges facing a directory administrator. This is because DNs traditionally begin with a common name (cn attribute). Common name-based distinguished names are not a problem for any kind of a directory entry other than entries that represent people. For people entries, common names are meant to be a person's full name. In theory, by using common name-based distinguished names you should be able to quickly know which person is represented by any given DN. Unfortunately, this strategy quickly fails because in any organization of even a moderate size, employees often have the same name.

To avoid naming collisions, use uid-based distinguished names for all person entries. Netscape SuiteSpot servers require that every person entry managed by the servers are defined to have a unique user ID anyway. By using this user ID for your distinguished names, you can elegantly sidestep directory name collisions.

Note that you should choose user IDs that are reasonably human readable; that is, do not use a random collection of letters and/or numbers for your user IDs. If your enterprise already has an email system, one possible solution is to select the left-most value on each person's email address for that person's user ID. That is, if a person has the email address:

bjensen@airius.com

then give that person's directory entry the following DN:

uid=bjensen, o=airius.com

Note It is recommended that you avoid using meaningless values such as an employee number for the uid. Using non-intuitive user IDs can create administrative burdens for you.

Also, remember that the information contained in a DN is essentially public information; anyone who can search for that entry can see all of the information contained in the DN. For this reason, limit your DNs to generic or public information. For more information on designing directory trees and DN formats, see Chapter 6, "Directory Tree Design."