This chapter describes how Oracle Communications Calendar Server uses Oracle Directory Server Enterprise Edition, what LDAP schema is necessary, and what specific object classes and attributes are required. Where appropriate, differences between Oracle Communications Calendar Server and Calendar Server 6 are described.
Calendar Server uses Directory Server to store and access LDAP data for individual users, groups, and domains. The LDAP data is used in a variety of ways, including:
Authenticating users
Determining a user's, group's, or domain's status
Administering domain level access control
Retrieving important information, such as the user's unique ID, email address, calendar store back-end ID, and so on
Retrieving default values for various user properties
You must install and provision Directory Server prior to installing and configuring Calendar Server. You also need to prepare the Directory Server LDAP schema by running the comm_dssetup.pl script, which is provided as part of the Unified Communications Suite installer. This script prepares the LDAP directory by adding the necessary Communications Suite schema. For more information, see the topic on comm_dssetup.pl in Communications Suite Installation Guide.
For information on installing and configuring Calendar Server, see Calendar Server Installation and Configuration Guide. In addition, perform post-configuration steps to enable certain levels of LDAP searches required for calendar searches and subscription, and to enable a secure connection between Calendar Server and Directory Server. See the topic on post-configuration tasks in Calendar Server Installation and Configuration Guide for more information.
To understand the schema that is used by Calendar Server, refer to Communications Suite Schema Reference. Specific LDAP object classes support Oracle Communications Calendar Server.
The davcore.ldapattr.* configuration parameters govern the default attributes and object classes used by Oracle Communications Calendar Server. Default values are set based on the Communications Suite schema. See the topic on configuration parameters in Calendar Server System Administrator's Guide for more information.
This section contains the following topics:
In Calendar Server 6, a user's LDAP entry requires the icsCalendarUser object class for calendaring to work for that user. Unless disallowed by the server configuration, Calendar Server 6 automatically provisions users by adding the icsCalendarUser object class to LDAP, creating the database entries for the user, and thus enables calendaring for the user upon first login or invite. Basic provisioning of the user entry in the LDAP directory is required for this to work.
Unlike Calendar Server 6, Oracle Communications Calendar Server does not add or modify LDAP data nor does it require the presence of a particular LDAP object class like icsCalendarUser. Unless disallowed by the server configuration, Oracle Communications Calendar Server automatically creates the database entries for a user upon initial login or invite, thus enabling the user. Basic provisioning of the user entry in the LDAP directory is required for this to work.
In Calendar Server 6, you can use both the icsStatus or icsAllowedService attributes to enable or disable calendaring service. In Oracle Communications Calendar Server, you use only the icsStatus attribute to enable or disable the service. For more information, see the information on icsStatus in Communications Suite Schema Reference.
In Calendar Server 6, the icsDWPHost attribute specifies the user's back-end data store. In Oracle Communications Calendar Server, it is the davstore attribute.
The following Communications Suite LDAP attributes used by Calendar Server 6 are no longer used by Oracle Communications Calendar Server. These attributes are from the icsCalendarUser, icsCalendarResource, and icsCalendarDomain object classes:
icsAllowedServiceAccess
icsCalendar
icsCalendarOwned
icsDefaultSet
icsDWPHost
icsExtended
icsExtendedUserPrefs (but still used by Convergence)
icsFirstDay (but still used by Convergence)
icsFreeBusy
icsGeo
icsPartition
icsPreferredHost
icsQuota
icsSet
icsSubscribed
icsTimezone
nswcalDisallowAccess
aclGroupAddr
icsAlias
icsCapacity
icsContact
icsExtended
icsExtendedResourcePrefs
icsSecondaryowners
icsDefaultacl
icsAllowRights
icsAnonymousAllowWrite
icsAnonymousCalendar
icsAnonymousDefaultSet
icsAnonymousLogin
icsAnonymousSet
icsDWPBackEndHosts
icsExtendedDomainPrefs
icsDefaultAccess
icsDomainAllowed
icsDomainNotAllowed
icsMandatorySubscribed
icsMandatoryView
icsRecurrenceBound
icsRecurrenceDate
icsSessionTimeout
icsSourceHtml
The icsCalendarGroup, icsAdministrator, and icsCalendarDWPHost object classes are also no longer used by Oracle Communications Calendar Server.
This information can also be found in Communications Suite Schema Reference.
This section describes the following object classes:
This object class defines a user entry with calendar service. While addition of this object class for calendar users is recommended, it is not mandatory. By default, a user entry that contains the deployment's "Unique ID Attribute" (a unique identifier in the form of an LDAP attribute whose value is used to map each calendar account to a unique account in the Calendar Server database), and uid, password, and mail attributes, works as a valid calendar user entry. The icsCalendarUser object class gives you more flexibility in enabling and disabling calendaring for provisioned users by using the icsStatus attribute. To require addition of this object class for a user entry to be considered as a valid calendar user entry, set the value of the Calendar Server configuration parameter davcore.ldapattr.userobject to icsCalendarUser.
See Calendar Server System Administrator's Guide for more information on using the davcore.ldapattr.userobject configuration parameter.
This object class is required to define a resource entry with calendar service. A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status.
To use a different object class instead, set the custom value for the davcore.ldapattr.resourceobject configuration parameter. The icsCalendarResource object class provides the owner attribute that by default specifies the owner of the resource.
For more on resource accounts, see the topic on administering resource calendars in Calendar Server System Administrator's Guide.
This object class defines a domain entry with calendar-enabled users. It enables setting domain-level access control for calendar users' cross-domain access by using its icsDomainNames and icsDomainAcl attributes. See the topic on managing domain access controls in Calendar Server Security Guide for details. You can use the icsStatus attribute in this object class to enable or disable calendaring service for an entire domain.
This is a common object class that you can add to any of the others such as icsCalendarUser, icsCalendarResource, or icsCalendarDomain, to include some commonly needed attributes. This object class includes the davStore attribute that defines the back-end calendar store host for a user, or an entire domain in a multiple back-end setup. It also includes the davUniqueID attribute to specify a globally unique ID for any LDAP entry.
The Communications Suite schema does not define any specific group object classes. By default, Calendar Server considers entries with groupofuniquenames, groupofurls, or inetmailgroup object classes as groups. This is defined by the Calendar Server davcore.ldapattr.groupobject configuration parameter.
Group entries make it easy to invite a whole set of users, or to set access control for a whole set of users. Groups are identified by using their mail attribute value. To determine members of a group, Calendar Server uses LDAP attributes defined by the following configuration parameters:
davcore.ldapattr.dngroupmember: Defines members by using their distinguished name (dn); default value is uniquemember
davcore.ldapattr.mailgroupmember: Defines members by using their email address; default value is mgrprfc822mailmember
davcore.ldapattr.urlgroupmember: Defines members by using a URL; default value is memberurl
Note:
Both uniquemember and memberurl are considered for checking ACLs while mgrprfc822mailmember is not. Thus, members of a uniquemember or memberurl group can read, write, subscribe, and so forth, to a calendar depending on the ACL. In the majority of cases, use uniqueMember when configuring a calendar group. mgrprfc822mailmember is application specific and useful to invite users that are not part of your deployment.For more information, see the topics on inviting LDAP groups and managing dynamic group ACLs in Calendar Server System Administrator's Guide.
This section contains the following topics:
This attribute defines the unique value used as the database identifier for each account. This value is used internally to identify a user in other user's access control entries, subscription entries, and so on. The attribute chosen as the unique ID attribute must be present in all user, group, and resource LDAP entries for the deployment.
The uid attribute is required for all calendar and contact users and resources. While not unique across domains and not used as the deployment's unique identifier, the uid attribute is still used to search for users within a domain.
The nsUniqueId attribute was initially chosen to be used by Calendar Server for a unique ID. However, the nsUniqueId attribute is no longer recommended because the value cannot be preserved if the LDAP entry must be moved or recreated. The nsUniqueId attribute does guarantee that the value is unique throughout the Directory Server instance but unfortunately that is not enough. The recommendation is now to choose an attribute whose value can be guaranteed to be unique. In addition, you should add checking to your provisioning process and tools to ensure that the chosen unique ID attribute is defined for every entry and is indeed unique.
You can use the Calendar Server supplied davUniqueId attribute to define a unique ID for any LDAP entry. It is recommended that it be used as the value of the davcore.uriinfo.permanentuniqueid parameter. This parameter defines which attribute Calendar Server uses as the unique identifier for users, groups, and resources. Calendar Server also provides the populate-davuniqueid script to set this attribute's value for all existing LDAP entries to a unique value.
In the Calendar Server database, the unique identifier value is case sensitive. If you must move or recreate the corresponding LDAP entry, make sure to retain the case of the value as is. However, because the value is considered as case insensitive for LDAP comparisons, do not create a unique identifier value for another user or resource entry by just changing the case of the value.
By default, Calendar Server uses the mail attribute. This attribute is used for many important functions, such as the default account identifier for the davadmin command-line utility, the address to be used for scheduling, the default address for email notifications, and so on. The Calendar Server database also stores the value of this attribute. If scheduling is performed by using other mail attributes, such as mailAlternateAddresses, the values are canonicalized to the mail value before storing in the database. If you change the value of this attribute, you must perform additional steps to changing it in the LDAP directory. See the topic on changing a user's email address in the Calendar Server database in Calendar Server System Administrator's Guide for more information.
This attribute is also required for resource entries. Though resources do not receive email, Calendar Server uses this address value to identify and schedule the resource. Hence this value should be unique to the resource, and other values such as the owner's email address should not be used. For more information, see the topic on managing a resource calendar's mailbox in Calendar Server System Administrator's Guide.
By default, Calendar Server uses the icsStatus attribute to enable or disable a user for calendaring services. Absence of this attribute or a value of active indicates active status. Values of removed, deleted, or inactive disable the service. Any other value may also enable the service but is not recommended.
If a calendar account's LDAP icsStatus attribute is populated and is not set to active, the account is not searched nor are any results fetched for that account when running Calendar Server davadmin or WCAP commands. That is, Calendar Server returns search results only for active accounts and does not return unusable data such as inactive calendars.
By default, Calendar Server uses the davStore attribute, which indicates the back-end host that stores a user's data if the deployment is configured for multiple back ends. Also, if the deployment uses the Convergence client or has a Calendar Server 6 and Oracle Communications Calendar Server co-deployment setup, this attribute is required. In the latter two cases, if there are no multiple Oracle Communications Calendar Server back-end hosts, then the value used by default must be defaultbackend.
If your deployment consists of multiple back ends, you must use one of the store.dav.xx.backendid values previously configured to set as the value for the davStore attribute. You must explicitly provision this attribute on your back-end configuration. Neither Calendar Server nor Delegated Administrator automatically provision this attribute.
Once a user is active, do not change the davStore attribute value. To move users to another back-end store, see the topic on moving calendar users in Calendar Server System Administrator's Guide.
The attributes described in this section support authentication against an external Directory Server. For more information, see the topic on configuring external authentication in Calendar Server System Administrator's Guide.
externalAuthPreUrlTemplate: This attribute is used for authentication when using external Directory Servers. It is used to set the LDAP URL that defines how users must be searched for in the external Directory Server against which authentication is performed. This attribute belongs to the inetDomainAuthInfo object class.
externalAuthPostUrlTemplate: This attribute is used for finding the internal Directory Server entry for a user authenticated by using external Directory Servers. It is used to set the LDAP URL that must be used to map the external Directory Server authenticated user to a user in the internal Directory. This attribute belongs to the inetDomainAuthInfo object class.
Certain attributes need to be indexed for presence, equality, or sub-string search for better performance. Some of this indexing is done by Directory Server itself or by the comm_dssetup script. Use Table 3-1 to decide if you have the correct indexes. Use the dsconf list-indexes command to list the current indexes. (See the topic on listing indexes in Sun Directory Server Enterprise Edition 7.0 Administration Guide). Use the create-index command for creating new indexes. (See the topic on creating indexes in Sun Directory Server Enterprise Edition 7.0 Administration Guide).
Table 3-1 Attributes for Indexing
| Attribute | Index |
|---|---|
|
associatedDomain |
eq, pres |
|
cn |
eq, pres, sub |
|
inetDomainBaseDN |
eq, pres |
|
|
eq, pres, sub |
|
mailAlternateAddress |
eq, pres |
|
member |
eq |
|
memberOf |
eq, pres, sub |
|
objectClass |
eq |
|
owner |
eq |
|
sunPreferredDomain |
eq, pres |
|
uid |
eq |
|
uniqueMember |
eq |
If you are concerned about LDAP performance, check the LDAP access logs for the entry notes=U to find unindexed searches. For example:
[15/Feb/2012:06:45:11 -0800] conn=110405 op=13 msgId=21 - SRCH base="o=example.com,o=dav" scope=2 filter="(|(uid=cal*)(cn=*cal*)(mail=*cal*))" attrs="cn davStore icsStatus mail mailAlternateAddress nsUniqueId owner preferredLanguage uid objectClass isMemberOf uniqueMember memberURL mgrpRFC822MailMember kind" [15/Feb/2012:06:45:17 -0800] conn=110405 op=13 msgId=21 - RESULT err=4 tag=101 nentries=1000 etime=6 notes=U
Calendar Server creates two special users during the initial configuration, one for serving as a proxy to the Directory Server, and the other for acting as the administrator ID for Calendar Server itself.
Topics in this section:
Calendar Server uses a proxy user to bind to the Directory Server when making requests. This user belongs to the Calendar End User Administrators Group, which has proxy rights. This special Calendar Server user makes Directory Server requests on behalf of the end user for whom the request is being carried out. The proxy process takes into account the Directory ACIs for that particular end user. The DN (Distinguished Name) of this newly created user is added to the server configuration as the base.ldapinfo.ugldap.binddn, for example:
Server configuration option:
base.ldapinfo.ugldap.binddn=uid=cal-admin-sca-peanut.example.com-20111102184916Z,ou=People,o=example.com,o=isp
Sample LDIF file used to create that user and group in the Directory Server:
dn: cn=Calendar End User Administrators Group, ou=Groups, o=isp changetype: modify add: uniqueMember uniqueMember: uid=cal-admin-sca-peanut.example.com-20111102184916Z, ou=People, o=example.com,o=isp dn: o=isp changetype: modify add: aci aci: (target="ldap:///o=isp") (targetattr="*") (version 3.0; acl "Calendar Server End User Administrator Proxy Rights - product=davserver,schema 2 support,class=admin,num=1,version=1"; allow (proxy) groupdn="ldap:///cn=Calendar End User Administrators Group, ou=Groups, o=isp";)
The other special user that Calendar Server creates is the Service Administrator user, by default, the calmaster user. The Calendar Server base.ldapinfo.serviceadminsgroupdn configuration parameter specifies the name of an LDAP group for which membership in the group means super user privileges as far Calendar Server is concerned. The calmaster user belongs to this Service Administrators group and thus has full access to all users' calendaring information. Convergence always authenticates and proxies on behalf of the end user to Calendar Server as calmaster. You can add additional users to the Service Administrators group if you require that more users have these privileges.
The Calendar Server initial configuration script, init-config, creates the LDAP tree's base containers and the default domain if it does not already exist. It also sets up the special administrative groups and users previously mentioned. ACIs are also added to give read, search, and proxy rights to the administrative users. An ACI is also added to give read and search ACIs to all authenticated users.
You may also want to enable users to search for other users whose calendars they can subscribe to. This requires permission to search for other users in LDAP. If such a permission is not already granted, you must add an ACI to the user/group suffix in Directory Server. For more information, see the topic on adding LDAP access control in Calendar Server Installation and Configuration Guide.
The following information describes how Directory Server authenticates a Calendar Server user by using basic user ID and password authentication.
Topics in this section:
Most requests to Directory Server are made against the user/group LDAP server (as defined in the base.ldapinfo.ugldap.* Calendar Server configuration parameters). Only the bind request to check the user's credentials is issued against the authentication LDAP server (as defined in the base.ldapinfo.authldap.* configuration parameters).
When an external directory is configured for the user's domain, a search is first issued against that external directory. The bind request to check the user's credentials is also issued against that external directory. Most of the information discovered through this process (including a hash of the logged-in user passwords) is cached in memory (with a configurable time-to-live value).
Consider the following search request:
Search Request: base DN = o=dav, scope = 2, filter = &(objectClass=sunManagedOrganization)(|(sunPreferredDomain=example.com)(associatedDomain=example.com))
The domain lookup is performed as follows:
The base DN (the top-level of the Directory Server tree) for this search is determined by the base.ldapinfo.dcroot Calendar Server configuration parameter.
The domain value is extracted from the user-provided user ID by using the base.ldapinfo.loginseparator Calendar Server configuration parameter. For example, if arnaudq@example.com is the user ID and the login separator character is "@," the domain is determined to be example.com).
Alternatively, if no login separator is found in the user ID, the domain is assumed from the base.ldapinfo.defaultdomain Calendar Server configuration parameter. An LDAP lookup is still issued in that case.
The default behavior is to use the user/group server and the authentication server for authentication.
If the domain entry retrieved in the previous step has an externalAuthPreUrlTemplate LDAP attribute, the user authentication is performed against an external directory.
To illustrate how the user (user/group server) authentication is performed, consider the following search request:
Search Request: base DN = o=example.com,o=dav, scope = 2, filter = uid=arnaudq
The base DN for this search is extracted from the domain entry retrieved during the initial domain lookup (with some differences between Schema 1 and Schema 2). Next, the search filter is constructed either from the inetDomainSearchFilter LDAP attribute of the domain entry or from the base.ldapinfo.searchfilter configuration parameter. In both cases, the configuration value is based on the following template:
%U: Name part of the login name (that is, everything before the login separator stored in the servers configuration)
%V: Domain part of the login string
%o: Original login ID entered by the user (for example, uid=%U)
This lookup should return an LDAP entry containing, in addition to a DN, the list of attributes defined by the base.ldapinfo.userattrs configuration parameters (the default is mail and ismemberof).
Consider the following bind request:
Bind Request: version = 3, DN = uid=arnaudq,ou=people,o=example.com,o=dav
Unlike the other requests, this one is made by using the authentication LDAP Server. The DN used is the one retrieved during the authentication user lookup step and the password is the one provided by the end user. Assuming that the bind request is successful, the LDAP entry returned during the authentication user lookup step is used to:
Check whether the corresponding user belongs to the administrative group.
Extract the mail attribute of the entry (the attribute name itself is configurable through the davcore.ldapattr.mail Calendar Server configuration parameter). Pay attention to this configuration parameter, as it is also used in different other places.
The authentication ends at this point. A set of principal objects containing the mail value (and optionally administrator privileges) are constructed as a result.
The externalAuthPreUrlTemplate LDAP attribute contains an LDAP URL defining what external directory server to use, and the type of search to issue to find the user within that directory. The host name part of the URL contains some identifier pointing to an actual LDAP Pool defined in the server configuration. The search filter in that LDAP URL is also a template, containing the same keywords as previously described (%o, %U, and %V). Once the entry is found, the credential verification (as previously described) is performed by using that entry's DN. The process of configuring external authentication for a particular domain is described by the topic on configuring external authentication in Calendar Server System Administrator's Guide.
Consider the following search request:
Search Request: (base DN = o=example.com,o=dav, scope = 2, filter = |(mail=arnaud.quillaud@example.com)(mailalternateaddress=arnaud.quillaud@example.com)
While not exposed, externally, the set of (JAAS) authentication modules is configurable. The domain lookup, authentication user lookup, and credentials verification steps correspond to the basic LDAP Auth module but other modules can be plugged in. The contract between an Auth Module and the server is that after successful authentication, the mail attribute of the principal must be made available to the server. Once the mail attribute value is extracted, a new lookup based on that email address is issued. This lookup is part of the core server processing.
The base DN for this search is extracted from the domain part of the email address (as described in "First Step: Domain Lookup on UG Server" although this information is already most likely cached at that point). The search filter is constructed from the davcore.uriinfo.emailsearchfiltertemplate configuration parameter (the default value is |(mail=%s)(mailalternateaddress=%s)). The returned entry is used to retrieve user information. The list of requested attributes is controlled by the davcore.uriinfo.subjectattributes configuration parameter.
Once the external directory has authenticated the user, a mapping needs to happen between that entry and the corresponding entry in the Communications Suite directory.
If all external directory user entries have a mail attribute value corresponding to their Communications Suite equivalent entry, no further configuration is required that is different from the internal authentication setup described previously. At the "Second Step: User Authentication", the list of attributes to be retrieved must simply include the mail attribute.
If no such direct mapping exists, an LDAP search is issued against the internal Communications Suite directory. This second search is defined by the externalAuthPostUrlTemplate domain entry attribute. Like externalAuthPreUrlTemplate, the externalAuthPostUrlTemplate attribute contains an LDAP URL defining what type of search to issue to find the user within that directory. In this case, a server name is not required and should not be defined, as the lookup is done against the Communications Suite directory. The search filter can be a template or fixed filter. They can contain the patterns previously mentioned, as well as the %A attributename_ pattern, which is substituted with the first LDAP attribute value retrieved from the external authentication directory in the "Second Step: User Authentication". This pattern may appear multiple times with different attribute names. Of course, those attributes must be part of the list of attributes to retrieve in the LDAP URL.
For a given login ID and domain, those patterns are substituted for their actual values before the search is issued. The search is then conducted, the correct entry is found, and the authentication is considered successful.
See Communications Suite Schema Reference for more information on the externalAuthPostUrlTemplate and externalAuthPreUrlTemplate attributes.
The following sample LDIF file is for a user that has access to Calendar Server. The user was created in Delegated Administrator. Delegated Administrator does not distinguish between Calendar Server 6 and Oracle Communications Calendar Server users. It includes object classes from both Calendar Server 6 (icsCalendarUser) and Oracle Communications Calendar Server (davEntity).
dn: uid=caluser1, ou=People, o=example.com, o=dav
sn: NS
givenName: CalUser
inetUserStatus: active
icsStatus: active
userPassword: {SSHA}GFxOCTbnS90zfWmqmvTgc51gOK36AOUCqXzZRA==
cn: caluser1
uid: caluser1
objectClass: sunUCPreferences
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: inetUser
objectClass: ipUser
objectClass: inetmailuser
objectClass: icscalendaruser
objectClass: inetlocalmailrecipient
objectClass: userpresenceprofile
objectClass: daventity
davUniqueId: c4df2181-422a11dd-8002d2ed-c263972e
mail: caluser1@example.com
mailAlternateAddress: caluser1@mail.domain1.example.com
mailHost: mail.example.com
mailUserStatus: active
mailDeliveryOption: mailbox