Using an external LDAP directory

---

CorporateTime Server can share information seamlessly with other back end infrastructure components such as e-mail servers through the use of an external directory server. Benefits include centralized user administration and consistency of information across multiple applications.

This chapter contains an overview of how directory servers interact with CorporateTime Server and a discussion of some more specific configuration issues.

Remember to also consult Appendix F, "Connecting to your Directory Server," for any additional configuration requirements that apply to your particular directory server.

• Why use a directory server?
• What is an LDAP Connector?
• Access control
• Directory server groups and group filters
• Binding
• Failover
• Security

Why use a directory server?

A directory server is a database application that stores information about users, and makes this information available to various other services, such as e-mail or calendar applications. Directory servers centralize user information; in the event that an administrator has to add or change user accounts, the task only needs to be done in one place instead of many. At the same time, user information is always kept consistent between all the applications that use the directory server; your user profile in your e-mail client, for example, will be the same as what you see in your calendar client.

CorporateTime Server integrates with a range of directory servers that use the Lightweight Directory Access Protocol, or LDAP, for accessing user records. Those records are kept in a hierarchical tree, in which each record is accessible through a particular path (called a Distinguished Name, or DN) that specifies the record's unique location in the tree. This is analogous to the way a filename and path such as /users/unison/misc/unison.ini specifies the location of a particular item in a file system.

Directory servers have schemas that define the information they store. These schemas consist of objects and attributes. Objects are representations of real-world people or things, and attributes are defining characteristics of those objects. Directory servers come with preset schemas to represent people and things, providing attributes for names, addresses, phone numbers, and so on, that define an `e-mail person'. You can also extend these schemas with new object classes and new attributes to reflect any information you care to store.

In order to use an LDAP directory with CorporateTime Server, you must extend the schema of your directory server with some new objects and attributes that are required by the calendar server, to define a `calendar person'.

What is an LDAP Connector?

LDAP Connectors contain all the object class and attribute extensions that the calendar server requires. In order for the calendar server to store and access information in your directory server, you must first apply a Steltor LDAP Connector to your directory server.

LDAP Connectors are available for a range of leading directory server products. For installation instructions and a complete list of supported products, consult your calendar server's readme and release notes files, available on-line at the Steltor Web site (http://www.steltor.com).

LDAP Connectors extend your directory server schema with three new object classes: ctCalUser, for calendar users; ctCalResource, for calendar resources; and ctCalAdmin, for calendar server administrative accounts such as the SYSOP. These classes also contain a number of calendar-specific attributes, all prefixed by the label "ctCal". These attributes store a variety of information, including user preferences and mobile settings. Consult Reference Appendix E, "Extensions to Directory Server Schema," for full details on these attributes.

Base DN

The calendar server requires a base DN, which is a location in the LDAP directory server under which all calendar users, resources and administrators will be located, and under which all directory searches will be performed.

Access control

Using calendar clients and server tools, both calendar users and administrators have the ability to modify entries in the LDAP directory. The level of access they have depends upon access the control restrictions set on your directory server. By default, calendar users can modify any of their own attributes, and calendar administrators (SYSOPs) have full control over all LDAP attributes under the calendar base DN.

Calendar users are created by adding an object class (ctCalUser) and a number of calendar attributes (identified by the "ctcal" prefix) to existing users. They bind to the directory server as themselves, using the self entry modification access control profile (ldap:///self), which on most directory servers grants full access to modify all attributes of that user. This includes both calendar-specific attributes and other user attributes such as e-mail address and mobile phone number.

Calendar administrators are added to the directory server as members of the group specified by the unison.ini parameter [LDAP] admingroup. When you install the calendar server, a default access control profile is created for members of this group which allows access to all LDAP attributes under the calendar base DN.

If you are familiar with your LDAP directory server's access control information, you may wish to configure it to restrict administrator and user permissions. Your directory server may or may not support access control restrictions at the necessary level of granularity. Consult your directory server documentation for details on configuring access control information. You must ensure that certain permissions remain at a minimum to avoid calendar client and server errors; detailed information on your calendar server's minimum requirements for user and administrator access control can be found at:

http://www.steltor.com/notes/corptime-server/5_3/aci.pdf

Directory server groups and group filters

Steltor calendar clients, such as CorporateTime for Windows, Macintosh and Motif, or CorporateTime for the Web, allow users to view and create groups of calendar users. If any groups exist in the LDAP directory server, these groups will also be available for viewing (but not modification) in the calendar client.

By default, all groups in the directory server located under the calendar base DN will be listed in the calendar client. However, since the calendar client will only display calendar users (i.e. users with the ctCalUser object class), if a given LDAP group has only non-calendar users as members, that group will be listed as empty, with no members at all.

To prevent calendar clients from listing such groups, you can configure the search filter the calendar server uses when looking for groups on the directory server. To do this, use the unison.ini parameter [LDAP] groupfilter. By default, the value of this parameter retrieves all groups. You can restrict it by applying a new object class to all groups you want to be listed, and adding this object class to the groupfilter parameter.

For example, consider the following two groups:

group 1:

dn: cn=Marketing Group, o=acme

objectclass: top

objectclass: groupOfUniqueNames

cn: Marketing Group

description: Marketing mailing-list group

uniqueMember: cn=Beverly Cleary,o=acme

uniqueMember: cn=Friedrich Schiller,o=acme

uniqueMember: cn=Philip MacDonald,o=acme

group 2:

dn: cn=Finance Group, o=acme

objectclass: top

objectclass: groupOfUniqueNames

cn: Finance Group

description: Finance mailing-list group

uniqueMember: cn=Ambrose Bierce,o=acme

uniqueMember: cn=Willa Cather,o=acme

uniqueMember: cn=Jamaica Kincaid,o=acme

If the Finance Group were composed only of non-calendar users, you could prevent it from being listed in calendar clients by adding an object class such as:

objectclass: CalendarGroup

to the Marketing Group definition, and changing the value of the [LDAP] groupfilter parameter to:

"(&(objectclass=groupOfUniqueNames)(objectClass=CalendarGroup)

(uniqueMember=*))"

Binding

When users query the calendar server for lists of other users, resources or groups, the calendar server binds to the directory server using the "anonymous" profile.

If your directory server does not allow anonymous binding, or if you want to prevent the calendar server from binding anonymously, you can use the [LDAP] binddn and [LDAP] bindpwd parameters in unison.ini to specify a directory server user account and password with which to bind.

This bind DN will be used for all read access to the directory server (such as user and resource searches); however users and administrators still bind to the directory server as themselves when performing modifications to item records.

Failover

You can specify an alternate directory server to be used in the event that your main directory server becomes unavailable. The unison.ini [LDAP] host parameter lists the directory server hosts in preferred order; if multiple hosts are listed and the first host listed becomes unavailable, the calendar server will instead attempt to connect to the next host listed. Consult the documentation on the [LDAP] host parameter in Reference Appendix B, "Server Parameters," for full details.

NOTE

After switching to a secondary directory server, the calendar server will not attempt to reconnect to the primary directory server in the event that it becomes available again. To reconnect to the primary directory server, stop and restart your calendar server, or, at a minimum, stop and restart the unidasd daemon using the unistart and unistop utilities with the -das option, available on UNIX platforms only.

Security

For greater security, you can protect the connections between your calendar server and directory server using the Secure Sockets Layer (SSL) protocol. If you choose to use SSL, you must enable it on both your directory and calendar servers. Consult your directory server documentation for instructions on setting up SSL on your directory server.

Setting up SSL on your calendar server

1. Download the SSL SDK for your calendar server platform from 1. www.iplanet.com. Version 4.1 is currently certified for all platforms.
2. If you have not already installed your calendar server, follow the directions given in the Readme file When specifying the URL of your directory server, make sure you use the directory server port, not the directory server's SSL port. Make sure your calendar server is not running before you proceed.
3. Copy the SSL SDK libraries to your calendar server's bin directory.
4. Run Netscape Navigator on the calendar server host, and access your directory server using its secure port. For example:

   https://<yourDSname>:<yourSSLport>/

   In the pop-up site certificate window, select Accept the certificate forever.

5. Find the cert7.db file on your system (likely in the netscape/users/<username> directory). Take note of this file's location.
6. Edit your unison.ini file, and add or modify the following parameters:

   [LDAP]

   
   

   security = TRUE

   
   

   secure-port = 636 (encryption port set on your directory server)

   
   

   certdbpath = "<pathname>" (the value from step 5)

   
   

   ldapssllibname = <LDAPlibraryName>

   lberssllibname = <LBERlibraryName>

   Consult Reference Appendix B, "Server Parameters," for more information on these parameters and their correct values for your operating system.

7. If you are running your calendar server on Linux, edit the /etc/ld.so.conf file to include your calendar server's bin directory. Make sure you are logged in as root, and run:

   /sbin/ldconfig

   followed by:

   ldd libldapssl41.so

8. Restart your calendar server. All further communications with the directory server will use SSL.

Copyright information