This chapter provides instructions for Oracle Communications Calendar Server post-installation tasks.
Calendar Server requires a unique identifier in the form of an LDAP attribute whose value is used to map each user account to a unique account in the database. The current default and recommended attribute, davuniqueid, prevents a potential serious issue with using nsUniqueId. If you use nsUniqueId and the LDAP entry for a user, group, or resource is deleted and recreated in LDAP, the new entry would receive a different nsUniqueId value from the Directory Server, causing a disconnect from the existing account in the calendar database. As a result, recreated users cannot access their existing calendars.
To change the unique identifier:
Run the davadmin config command to modify the davcore.uriinfo.permanentuniqueid configuration parameter. This parameter specifies the unique valued LDAP attribute present in the LDAP entry of all subjects (users, groups, and resources).
See the topic on command-line utilities in Calendar Server System Administrator's Guide for more information about the davadmin command.
Caution:
Changing this option after any user data is created in the database leads to data loss.Calendar Server performs searches on the index you chose to use for davcore.uriinfo.permanentuniqueid. The installation process automatically creates the Directory Server index for davuniqueid. If you did not choose to use the default value of davuniqueid for davcore.uriinfo.permanentuniqueid, you must index the chosen attribute for presence and equality ([pres.eq]) in Directory Server. For more information about working with Directory Server indexes, refer to the Directory Server documentation.
Add the attribute to the list of LDAP attributes fetched by Calendar Server by running the davadmin config modify command to change the davcore.uriinfo.subjectattributes configuration parameter. Make sure to add on to the existing list and pass the entire value when doing the modification.
To enhance security within your installation, you can configure Calendar Server to scan attachments for viruses. Calendar Server virus scanning can examine attachments in a real-time mode to test and optionally reject incoming infected data. You can also choose to scan and optionally delete infected existing data on-demand.
To enable Calendar Server for virus scanning, see the topic on configuring and administering virus scanning in Calendar Server System Administrator's Guide.
This section provides sample ACIs that show the attributes that Calendar Server needs for granting end users permission to search the LDAP directory for other users and resources whose calendars they can subscribe to. Tailor these samples to your individual site's security needs.
You add an ACI to the user/group suffix in Directory Server by using the ldapmodify tool. For more information on creating ACIs, see the topic on creating, viewing, and modifying ACIs in Oracle Directory Server Enterprise Edition Administration Guide 11g Release 1 (11.1.1.5.0).
Sample ACIs:
The following sample ACI enables users to search for all other users and resources in the same domain for all domains hosted in the Directory Server, assuming a suffix of o=isp.
dn: o=isp changetype: modify add: aci aci: (target="ldap:///($dn),o=isp") (targetattr!="userPassword") (targetfilter=(|(objectClass=icscalendaruser)(objectclass=icscalendarresource))) (version 3.0; acl "CS User search access to all users and resources in own domain - product=davserver,class=install,num=3,version=1"; allow (read,search) userdn="ldap:///[$dn],o=isp??sub?(objectclass=icscalendaruser)";)
To control domain access at a finer level, add individual ACIs instead of using the $dn macro. For example, to allow search for only one domain, set the following ACI on the domain organization entry.
dn: domainA.orgdn changetype: modify add: aci aci: (targetattr!="userPassword") (targetfilter=(|(objectClass=icscalendaruser)(objectclass=icscalendarresource))) (version 3.0; acl "CS User search access to all users and resources in domain A - product=davserver,class=install,num=3,version=1"; allow (read,search) userdn="ldap:///domainA.orgdn??sub?(objectclass=icscalendaruser)";)
Replace domainA.orgdn with your organization DN.
When adding ACIs to enable users to search other domains, that is, cross-domain searches, keep the following in mind:
For domain A users to be able to search for users in domain B, you would add an ACI on domain B's node that allows the search from users in domain A. For example, to enable users in example.com to search users in varrius.com, add the following ACI to the domain entry for varrius.com domain o=varrius.com,o=isp by using the ldapmodify command:
dn: o=varrius.com,o=isp changetype: modify add: aci aci: (targetattr!="userPassword") (targetfilter=(|(objectClass=icscalendaruser)(objectclass=icscalendarresource))) (version 3.0; acl "example.com users access in varrius.com - product=davserver,class=install,num=3,version=1"; allow (read,search) userdn="ldap:///o=example.com,o=isp??sub?(objectclass=icscalendaruser)";)
You might also need to set domain Access Control Lists (ACLs) to control calendar operations that span multiple domains. Calendar Server combines domain ACLs with the calendar and scheduling ACLs to grant or deny levels of access to these operations. All operations within a single domain rely strictly on the calendar and scheduling ACLs. For more information, see the topic on managing domain access controls chapter in Calendar Server Security Guide.
Messaging Server is capable of posting a calendar event received in an iCalendar Message-Based Interoperability Protocol (iMIP) message to Calendar Server by using the iSchedule protocol. This capability enables "internal" users to automatically process calendar invitations from "external" users.
To enable this interoperability between calendaring systems, you configure a Messaging Server "iSchedule" channel to process the iMIP messages. For more information, see the topic on using the iSchedule channel to handle iMIP messages in Messaging Server System Administrator's Guide.