3
Using Oracle Internet Directory

The Oracle Calendar server can share information seamlessly with other back end infrastructure components such as e-mail servers through the use of Oracle Internet Directory. Benefits include centralized user administration and consistency of information across multiple applications.

This chapter contains an overview of how the Oracle Internet Directory interacts with Oracle Calendar server, and a discussion of some more specific configuration issues.

Benefits of using Oracle Internet Directory

Oracle Internet Directory 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 like Oracle Internet Directory 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.

Oracle Calendar server integrates with Oracle Internet Directory, which uses 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.

When you install Oracle Internet Directory as a part of Oracle Collaboration Suite, it will be preset with all the objects and attributes needed by the calendar server.

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; for detailed information on your calendar server's minimum requirements for user and administrator access controls contact Oracle support.

Directory server groups and group filters

Oracle calendar clients 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.

Remember that you must encrypt the value of the bind password before including it in the unison.ini file. Use the uniencrypt utility with the -s argument, and include the entire output, enclosed within double quotes as the parameter value. For details on the use and syntax of uniencrypt, see the calendar server Reference Manual, Appendix C, "Utilities."

Failover

You can specify an alternate directory server host to be used in the event that your main host 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 the calendar server Reference Manual, 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, the connections between your calendar server and directory server will be protected by default using the Secure Sockets Layer (SSL) protocol. Without the use of SSL, passwords may be sent across the wire in clear text.

Changing the attribute used for SSO login

If you change the attribute your Oracle Internet Directory uses to authenticate SSO logins at any time after you have installed the calendar server, it is vital that you perform the following calendar server configuration change. If you do not, users will be unable to sign in using Web clients, and the integrity of your calendar database may be threatened.

Stop all calendar servers in your network.
Edit the /users/unison/misc/unison.ini file on each calendar server host, and modify the value of the following parameter:
```
[LDAP]
attr_uid = <attribute_used_for_login>
```
This parameter controls the directory server attribute the calendar server uses as a unique user identifier.
Restart all servers stopped in step 1.

3 Using Oracle Internet Directory