This chapter describes how to provision Oracle Communications Calendar Server users and manage calendar accounts.
This section describes how to provision Calendar Server users and contains the following topics:
Calendar Server uses Directory Server to store and retrieve user and resource information and to perform authentication. Calendar Server does not add or modify LDAP data. Calendar Server data (such as todos and events) is stored in an SQL database, which can be either MySQL Server or Oracle Database.
Note:
Oracle Communications Calendar Server supports the same LDAP schema used by Calendar Server 6. Some additional object classes and attributes were added for Oracle Communications Calendar Server.By default, Calendar Server automatically creates the necessary entries in the SQL database for users upon their initial Calendar Server login. However, you must also perform some basic LDAP user provisioning for users and resources to be able to access Calendar Server services, and for Calendar Server automatic account creation to work. You can provision Calendar Server users and resources in the Directory Server LDAP by using either Delegated Administrator or LDAP tools.
You must provision Calendar Server users and resources so that Calendar Server can automatically create accounts and users and resources can access Calendar Server services. You must provision users and resources with the following attributes:
An email attribute, such as mail.
A unique ID attribute corresponding to the value for the server davcore.uriinfo.permanentuniqueid configuration parameter. The default value is davUniqueId. Be sure to also index the attribute used for davcore.uriinfo.permanentuniqueid, as Calendar Server performs searches on it.
To define these attributes, the corresponding object classes must be present in LDAP. The davEntity object class defines the davUniqueId attribute. In addition to the preceding two LDAP requirements, if your deployment consists of multiple back-end databases, you must define the Store ID attribute. The davEntity object class also defines the default Store ID attribute. The default value for Store ID is davStore.
By default, if you provision Calendar Server users for email and unique ID attributes (and the Store ID attribute when multiple back-end databases are deployed), users have a status of active. The active status enables users to access Calendar Server services. To deny Calendar Server services to users, you specify a value of either inactive or deleted for the user's icsStatus attribute.
If you have a co-existent deployment of both Calendar Server 6 and Oracle Communications Calendar Server, and are migrating users to Oracle Communications Calendar Server, you must update the user's LDAP once the user is marked for migration and taken offline for migration. You can only migrate the user at that point. Calendar Server uses an LDAP attribute to determine if a user has been migrated. By default, the davStore attribute is used, but you can choose another attribute if desired. In a single back-end deployment, this attribute must be added with the value of defaultbackend. In a multiple back-end deployment, the value must be the logical back-end ID for the database where the user's data resides after migration. Again, the object class that defines the davStore attribute is davEntity.
For more information on Calendar Server LDAP schema, object classes, and attributes, see Calendar Server Concepts and Communications Suite Schema Reference.
Delegated Administrator 7 supports Calendar Server provisioning. Calendar Server makes use of the davStore attribute and not icsdwphost (which is used in Calendar Server 6) to assign a specific back-end in a multiple back-end scenario. You can add the davStore LDAP attribute to users' and resources' subject entries to associate those users and resources with a particular back-end Calendar Server store. The value of the davStore attribute is equal to one of the davStore IDs defined in the server configuration. davStore is single valued. When not present, a server configurable default davStore ID is used.
When a user or group is assigned a calendar service, the davEntity object class is added along with icscalendaruser or icscalendargroup object class, enabling you to provision the user or the group with a davStore attribute.
The new user wizard with the Calendar Service Details consists of the following fields:
Calendar Host
Calendar Store
Timezone
where the Calendar Host and Timezone are applicable to Calendar Server 6 and Calendar Store is applicable to Oracle Communications Calendar Server.
The user properties section in the Calendar Service Details consists of the following fields:
Calendar Host: (icsdwphost)
Calendar Store: (davstore)
Email Address: (mail)
Default Calendar: (icscalendar)
Owned Calendar: (icscalendarowned)
Subscribed Calendar: (icssubscribed)
Timezone: (icstimezone)
Calendar Service Status: (icsstatus)
where the Calendar Host, Default Calendar, Timezone, Owned Calendar, and Subscribed Calendar are applicable to Calendar Server 6 and Calendar Store is applicable to Oracle Communications Calendar Server. Email Address and Calendar Service Status are applicable to both servers.
A new field called Calendar Store is added for Oracle Communications Calendar Server users. When configuring a user in Delegated Administrator with Calendar services, a valid davstore ID has to be entered in the Calendar Store field instead of a host name.
Calendar Server supports hosted (or virtual) domains. In a hosted domain installation, each domain shares the same instance of Calendar Server, which enables multiple domains to exist on a single server. Each domain defines a name space within which all users, groups, and resources are unique. Each domain also has a set of attributes and preferences that you specifically set.
Installing and configuring hosted domains on a server involves these high-level steps:
Installing and configuring Calendar Server and Delegated Administrator.
For more information, see Calendar Server Installation and Configuration Guide and Delegated Administrator Installation and Configuration Guide.
Using Delegated Administrator to create the hosted domain, and users, resources, and groups in that hosted domain.
For more information, see Delegated Administrator System Administrator's Guide.
Setting domain ACLs.
For more information, see the topic on managing domain access controls in Calendar Server Security Guide.
Note:
Always perform your provisioning for Schema 2 with Delegated Administrator. Schema 1 provisioning tools do not support hosted domains.Managing calendar users and accounts includes:
Creating Calendar Account with Default Calendar Automatically Upon Login
Preventing a User or Resource From Accessing Calendar Server
Changing a User's Email Address in the Calendar Server Database
The davcore.ldapattr.userobject configuration parameter defines what LDAP object class is required for a calendar user entry to be considered valid. By default, davcore.ldapattr.userobject is empty. A value that would make sense is icsCalendarUser, however, if you use custom provisioning, you can define your own object class instead.
To define a valid calendar user:
Set the davcore.ldapattr.userobject configuration parameter to a valid LDAP object class. For example:
davadmin config modify -o davcore.ldapattr.userobject -v icsCalendarUser
Setting davcore.ldapattr.userobject to the LDAP attribute icsCalendarUser would consider users without that object class in their LDAP entries as invalid calendar users, therefore no auto-provisioning would take place for them in the calendar store.
You can enable or disable, on a system-wide basis, automatic account creation. When automatic account creation is enabled, users' accounts are automatically created for them when they first log in to Calendar Server.
To enable automatic calendar accounts creation:
davadmin config modify -o davcore.autocreate.enableautocreate -v true
To disable automatic calendar accounts creation:
davadmin config modify -o davcore.autocreate.enableautocreate -v false
See the davcore.autocreate.enableautocreate parameter in "Calendar Server Configuration Parameters" for more information.
To create accounts with default calendars automatically when users log in:
Create users by provisioning them in LDAP.
Use the davadmin command to set any of the davcore.autocreate.* parameters to customize your deployment.
See "Calendar Server Configuration Parameters" for more information.
Enable automatic account creation.
Provide users with instructions for logging in to Calendar Server.
To prevent a particular user from accessing Calendar Server, set the icsStatus attribute to inactive. You can set the icsStatus attribute on a user or resource, or domain basis. For more information on icsStatus, see Communications Suite Schema Reference.
Use the commands log to check for which users have been querying their calendars. In this way you can determine which users are active. For more information, see "Using the commands Log".
Tip:
Use a cron job script to automatically scan the commands log file and generate this kind of report.Completely removing a calendar user involves deleting the user from the Calendar Server database and the LDAP directory.
To remove a Calendar Server user:
Run the davadmin account delete command to delete the user account and calendars from the Calendar Server back-end database.
Set the icsStatus attribute for users being deleted to "removed."
You must do this so that the last step of deleting the account from LDAP by using the commadmin command is successful. Even when you delete the user account in previous step, the LDAP entry for the user remains with the icsStatus attribute unchanged. Thus, you must manually set the icsStatus attribute to "removed" so that running the Delegated Administrator commadmin domain purge command removes the user's LDAP entry.
Run the Delegated Administrator commadmin domain purge command to remove the user's LDAP entry.
Note:
The commadmin domain purge command does not, however, remove the user as a member from any groups of which the user is a member. To completely remove a user's entry from the directory, you must enable the Referential Integrity plug-in. See the topic on maintaining referential integrity in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition 11.When you remove a calendar user by running the davadmin account delete command, the back-end resources for the user are deleted, and then purged according to the value of the store.dav.defaultbackend.purgedelay configuration parameter. See "Removing Unwanted Calendar Data to Reclaim Space" for more information.
Note:
The search_calprops.wcap command does not return calendars belonging to accounts which have a status of 'inactive,' 'removed,' or 'deleted.'These steps show how to use the command-line to remove a calendar user. In this example, the user is:
dn: uid=jsmith,ou=People,o=us.example.com,o=isp
These steps use the ldapmodify command to make changes to the Directory Server LDAP. Other LDAP tools are also available.
In LDAP, search for the user(s) to be removed. For example:
ldapsearch -h ds.us.example.com -b "o=isp" "(uid=jsmith)" version: 1 dn: uid=jsmith,ou=People,o=us.example.com,o=isp ...
Run the davadmin command to remove the calendar account and its calendars from the Calendar Server back-end database:
CalendarServer_home/sbin/davadmin account delete -a jsmith@us.example.com Enter Admin password: Are you sure you want to delete the account of jsmith@us.example.com and all of its calendars (y/n)? [n] y
Verify that the calendar account has been removed from the Calendar Server back-end database:
CalendarServer_home/sbin/davadmin account list -a jsmith@us.example.com
Enter Admin password:
Unknown user: jsmith@us.example.com
Run the ldapmodify command to change the user's status to removed in LDAP:
ldapmodify -h ds.us.example.com -D "cn=Directory Manager" -w password dn: uid=jsmith,ou=People,o=us.example.com,o=isp changetype: modify replace: icsStatus icsStatus: removed ^D modifying entry uid=jsmith,ou=People,o=us.example.com,o=isp
Alternately, you can run the following commadmin command:
DelegatedAdmin_home/bin/commadmin user modify -D admin -d us.example.com -l jsmith -A icsstatus:removed
(Optional) If user account is configured for mail service, remove the service for the user and run the msuserpurge command to purge the account from the Messaging Server message store. For example:
DelegatedAdmin_home/bin/commadmin user delete -l jsmith -S mail MessagingServer_home/lib/msuserpurge -d us.example.com -g 0
The -g 0 option performs an immediate purge.
Run the commadmin command to purge the account:
DelegatedAdmin_home/bin/commadmin domain purge -D admin -n us.example.com -d us.example.com -g 0
Enter login password:
OK
The -g 0 option performs an immediate purge.
Verify that the user has been removed from LDAP:
ldapsearch -h ds.us.example.com -b "o=isp" "(uid=jsmith)"
Nothing is returned from this command, indicating that the user is no longer present in LDAP.
To move an existing calendar user from one back-end database to another:
Take the user offline by using the ldapmodify command to set the LDAP attribute icsstatus to inactive.
Back up the user's data by using the davadmin db backup command.
Delete the user's data from the old back-end database by using the davadmin account delete command.
Update the user's davStore attribute to the new back-end database by using the ldapmodify command.
Restore the user's data to the new back-end database by using the davadmin db restore command.
Re-activate the user by setting the LDAP attribute icsstatus to active.
Restart the application server.
Verify that the data has been successfully moved by having the user log in and view calendar data.
The following example shows how to move user caltest1@backend1.com from backend1 to the default back-end host1. In this example:
The default back end is on host host1 and the database name on the default back end is caldav.
The other back end is on host backend1 and the database name on backend1 is caldav_backend1.
The user caltest1@backend1.com has data located on backend1.
Take the user offline by using the ldapmodify command to set the LDAP attribute icsstatus to inactive.
ldapmodify -D "cn=Directory Manager" -w password dn: uid=caltest1, ou=People, o=backend1.com, o=dav changetype: modify replace: icsStatus icsStatus:inactive
Back up the user's data by using the davadmin db backup command.
davadmin db backup -u database_user -a caltest1@backend1.com -H backend1 -d caldav_backend1 -k caltest1.bak
Delete the user's data from the old back-end database by using the davadmin account delete command.
davadmin account delete -u admin_user -a caltest1@backend1.com
Update the user's davStore attribute to the new back-end database by using the ldapmodify command.
ldapmodify -D "cn=Directory Manager" -w password dn: uid=caltest1, ou=People, o=backend1.com, o=dav changetype: modify replace: davStore: davStore: defaultbackend
Restore the user's data to the new back-end database by using the davadmin db restore command.
davadmin db restore -H host1 -u database_user -d caldav -k caltest1.bak
Re-activate the user by setting the LDAP attribute icsstatus to active.
ldapmodify -D "cn=Directory Manager" -w password dn: uid=caltest1, ou=People, o=backend1.com, o=dav changetype: modify replace: icsStatus icsStatus: active
Restart the application server.
When a user undergoes an email address change, use this procedure to fix notification addresses, organizer addresses, attendee addresses, and alarm addresses in the Calendar Server database.
To change a user's email address in the Calendar Server database:
(Optional) If you are changing the email address because the user's mail domain has changed, move the user entry to the correct domain container in LDAP for the new domain. Be sure to retain the value of the davUniqueid attribute in the user's LDAP.
Add the previous email address value to the LDAP attribute defined as mailAlternateAddress, that is, the attribute defined by the davcore.ldapattr.mailalternateaddress configuration parameter.
Replace the value for the user's mail attribute in LDAP with the new email address.
Run the davadmin account repair -a command on the old email address. If the user's domain has changed, also use the -D option to specify the new domain value. See davadmin account in "Calendar Server Command-Line Utilities" for more information on this command.
(Optional) Remove the previous email value from the mailAlternateAddress values.
Calendar Server administrators can subscribe or unsubscribe calendars for a user by using the davadmin account command with subscribe or unsubscribe actions.
To subscribe a user to another user's calendar:
User A gives User B read, write, or all rights to User A's calendar.
User B is subscribed to User A's calendar:
davadmin account subscribe -a User_B -c User_A's_calendar
For example:
davadmin account subscribe -a userb@example.com -c /home/usera@example.com/calendar/
To unsubscribe a user from another user's calendar:
davadmin account unsubscribe -a User_B -c User_A's_calendar
For example:
davadmin account unsubscribe -a userb@example.com -c /home/usera@example.com/calendar/
To subscribe using a collection file:
Create a file such as /tmp/list_of_collections with the following content:
/home/usera@example.com/calendar/ /home/userc@example.com/cal1/ /home/userd@example.com/personal/
Run the following command:
davadmin account subscribe -a userb@example.com -C /tmp/list_of_collections
See the account Operation commands in "Calendar Server Command-Line Utilities" for more information.
Calendar Server enables user authentication against a separate, LDAP directory external to the Calendar server environment. Such a configuration is useful in hosted environments for delegating one administrative aspect to a provider (managing the Calendar Server front- and back-end hosts and LDAP directory with non-sensitive data), while maintaining control over the LDAP user passwords in the internal, corporate network. In this setup, Calendar Server uses the external directory for user authentication.
Configuring Calendar Server for external authentication consists of the following high-level steps:
Creating the LDAP pool for the external authentication directory
Specifying how to search for users in that directory
Specifying how to map the external user entry back into a Unified Communications Suite directory user entry
Use the davadmin ldappool command to create then verify an LDAP pool for the external authentication directory. For example:
cd CalendarServer_home/sbin davadmin ldappool create -n myldap -y 'ldaphost=ldap.example.com,ldapport=389,ldapusessl=true,binddn="cn=Directory Manager",bindpassword=password' Enter Admin password: password davadmin ldappool list Enter Admin password: Pool Name: myldap ldaphost: ldap.example.com ldapport: 389 ldapusessl: true ldappoolsize: 10 binddn: cn=Directory Manager bindpassword: ******** ldaptimeout: 60 ldappoolrefreshinterval: 1
You can also set other parameters, such as ldappoolsize and ldaptimeout. See the davadmin ldappool command in "Calendar Server Command-Line Utilities" for more information.
Define how to search for users in that directory by adding the externalAuthPreUrlTemplate LDAP attribute to each of the domain entries associated with that external directory. The attribute value is an LDAP URL (http://tools.ietf.org/html/rfc4516) of the following form:
ldap://server_name/search_base_DN?attributes?scope?search_filter
where:
server_name must correspond to a defined LDAP pool.
search_base_DN and search_filter can contain the following patterns:
%o (original login ID, as provided by the user over protocol)
%U (user part of login ID)
%V (domain part of login ID)
The % character in %o, %U, and %V needs to be encoded as per the general URI definition. That is, the % character becomes %25.
Define how to map the external user entry back into a UCS directory user entry.
Do the external directory user entries have a mail attribute value corresponding to their internal Unified Communications Suite directory attribute value?
If yes, no further configuration is required. (In Step 2, the list of attributes to retrieve should simply include the mail attribute.)
If no, define a search to be issued against the Unified Communications Suite directory by using the externalAuthPostUrlTemplate domain entry attribute. As with the externalAuthPreUrlTemplate attribute, the externalAuthPostUrlTemplate value is an LDAP URL of the following form:
ldap://server_name/search_base_DN?attributes?scope?search_filter
For more information, see the externalAuthPostUrlTemplate attribute description in Communication Suite Schema Reference.
Note the following:
The server_name is ignored and should be empty because the lookup is performed against the internal Communications Suite directory.
The attributes to be retrieved must include the mail attribute.
In this external authentication scenario, example.com is the default domain and uses the cn attribute as the login ID. Each user entry in the external authentication directory contains a ucsUid attribute value that corresponds to the internal Unified Communications Suite directory uid attribute value (in the Unified Communications Suite user entry). The LDAP pool is myldap and the following two attributes have been added to the example.com domain entry:
externalAuthPreUrlTemplate: ldap://myldap/dc=example,dc=com?ucsUid?sub?(cn=%25U) externalAuthPostUrlTemplate: ldap:///uid=%25A[ucsUid],ou=people,o=example.com?mail?base?(objectclass=*)
The LDAP entry in the external directory for a sample user, John Doe, looks like the following:
dn:cn=John Doe,ou=people,o=marketing,dc=example,dc=com cn:John Doe ucsUid:jdoe ...
The LDAP entry in the internal Unified Communications Suite directory for John Doe looks like the following:
dn:uid=jdoe,ou=people,o=example.com cn:Doe, John uid:jdoe mail:john.doe@example.com ...
The user authenticates by using the login ID John Doe. Given that this login ID has no domain part, the default domain (example.com) is assumed and the externalAuthPreUrlTemplate attribute of that domain entry is used to construct the following search against the server defined by authPool:
base DN: dc=example,dc=com
scope: subtree search
filter: (cn=John Doe)
attributes to retrieve: ucsUid
The entry dn:cn=John Doe,ou=people,o=marketing,dc=example,dc=com is returned and that dn is used to issue an LDAP bind request to verify the user's password.
That same entry (containing the ucsUid attribute) is used to construct a second search, against the Unified Communications Suite user/group directory:
base DN: uid=jdoe,ou=people,o=example.com
scope: base search
filter: (objectClass=*)
attributes to retrieve: mail
The correct entry is found and the authentication is considered successful.
You can configure Calendar Server for proxy authentication to enable a calendar administrator to log in to Calendar Server on behalf of a calendar user. For more information, see Calendar Server Security Guide.