Chapter 12 Administering Users and Resources

This chapter describes how to use the Calendar Server utilities to provision and manage users and resources. This chapter contains the following sections:

Two Provisioning Tools

Calendar users and resources can be provisioned and administered using either of the following provisioning tools:

Sun Java System Communications Services User Management Utility (commadmin) – Use this utility if you have Identity Server installed. See also the commadmin utility reference in the Sun Java System Communications Services User Management Utility Administration Guide at:

Command-line utilities (csuser and csresource) – Use these utilities if you had an earlier version of Calendar Server or Messaging Server installed using Sun LDAP Schema 1 and plan to continue using Schema 1 (you are NOT using Identity Server). See also the command-line utility reference in this guide, Appendix D, "Calendar Server Command-Line Utilities Reference".



Note	In certain cases, even if you are using Schema 2 and the User Management Utility, you will need to use some of the Calendar Server command-line utilities to perform special functions. When this is necessary, task oriented documentation in this guide will tell you which utility to use.

Preparing to Provision Users and Resources

This section provides the following information about provisioning new Calendar Server users:

Required mail Attribute

Calendar Server requires users and resources to have the mail attribute. Calendar Server allows people to search for calendars and resources using an email address or a calid.

For Existing Users and Resources

If you need to add the mail attribute to existing users and resources, use the Calendar Server csattribute utility or a utility such as Directory Server’s ldapmodify.

The following example adds the LDAP mail attribute for an existing conference room named “Room100” on the sesta.com server. This example uses Sun Java System Messaging Server. If you are using another email server, refer to that product’s documentation for the equivalent process.

Add the mail attribute to the LDAP entry using the csattribute utility:

# ./csattribute -a mail=Room100@sesta.com add Room100

To check that the attribute has been set, use the csattribute list command with the -v (verbose) option:

# ./csattribute -v list Room100

...

cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com

For New Users and Resources

If you create new users or resources after installation and migration, use the required -m email option to specify an email address when you run csuser or csresource.

For information about the cs5migrate migration utility, refer to the Sun Java System Calendar Server 6 2004Q2 Administration Guide.

For information about ldapmodify utility, refer to the Sun ONE Directory Server Resource Kit 5.2 Tools Reference, which is available on the following Web site:

Example: Setting up a bitbucket Channel for a Resource’s Email

The following examples set up a bitbucket channel for Messaging Server and Sendmail for the email generated for resource calendars. These examples use a resource named “Room100” on the sesta.com server. If you don’t set up the bitbucket channel (or equivalent), you will need to periodically delete the email messages sent to the resource calendar.

Ensure the bitbucket channel is defined in the imta.cnf file.

To direct messages to the bitbucket channel, create the email address for the resource using the csattribute utility:

# ./csattribute -a mail=Room100@bitbucket.sesta.com add Room100

In the /etc/aliases file on the appropriate host, add an entry such as:

# Resource/Conference room aliases
Room100: /dev/null

Add the email address for the resource to the LDAP directory using the csattribute utility:

# ./csattribute -a mail=Room100@sesta.com add Room100

Email Alias (mailalternateaddress Attribute)

If you need to setup an email aliases for a calendar user, use the LDAP mailalternateaddress attribute. The LDAP mail attribute provides the primary mail address, and the LDAP mailalternateaddress attribute is used for email aliases. Both attributes map the mail addresses to the user’s calendar ID (calid).

For example, to add the mailalternateaddress attribute for a user named John Smith with these values:

User ID (uid) and calid: johnsmith

password: password for John Smith

Email address: john.smith@sesta.com

Email aliases: johns@sesta.com and jsmith@sesta.com

# ./csuser -g John -s Smith -y password -l en -m john.smith@sesta.com create johnsmith
# ./csattribute -a mailalternateaddress=johns@sesta.com add johnsmith
# ./csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith



Note	To enable these changes, you might also need to rebuild alias tables or configurations. Refer to the documentation for Messaging Server (or your email product) as well as your site's own documentation and procedures regarding changes to mail services. Messaging Server is available on this Web site: http://docs.sun.com/coll/S1_MsgServer_60

Checking if a User is Enabled for Calendaring

To determine if a specific user exists in your directory server and is enabled to access Calendar Server data, use the csuser utility check command.

If the check command indicates that a user does not exist in your LDAP directory server, you must create a directory server entry for the user.

Enabling a User

To enable a user, use either commadmin user create (for Schema 2), or csuser enable (for Schema 1). If you used csuser create when you created the user entry, the user is automatically enabled.

If a user sends a request to another user who has not been enabled for calendaring (that is, the user does not have a default calendar), Calendar Server returns the “Calendar not found” error to the user sending the request.

Managing Calendar Server Users

After your users are provisioned, use the csuser utility to perform the following administrative tasks:

Displaying User Information

To list all calendar users or to display the calendar attributes of a specified user, use the csuser utility list command.

Disabling and Enabling a User

To prevent a user from logging into Calendar Server, use the csuser utility disable command. The disable command prohibits a user from accessing calendar data, but it does not remove the user’s information from the directory server or the Calendar Server database.

This command prevents jsmith from logging into Calendar Server to access calendar data, but jsmith’s data is not deleted from the calendar database. However, if jsmith is currently logged into Calendar Server, jsmith retains access to calendar data until logging off.

To enable a user to access Calendar Server and optionally to assign specific configuration settings such as a default calendar, use the csuser utility enable command.

For example, to enable jsmith to access (log into Calendar Server) and to assign jsmith a default calendar:

Deleting a User



Caution	The csuser utility delete command removes all of the user’s Calendar Server information from the LDAP server. You can recover Calendar Server database information if the calendar database has been backed up. For more information, see Chapter 15, "Backing Up and Restoring Calendar Server Data". However, you can recover the LDAP server information only if you have specifically backed it up.

Resetting a User’s Attributes

To restore the default settings of all calendar LDAP attributes for a specific user, use the csuser utility reset command.

For example, to reset all calendar attributes of jsmith to the default configuration settings:



Note	After a calendar user has been reset, all of the calendar attributes are removed from the user’s LDAP entry, including icsCalendarUser (object class), icsSubscribed, icsCalendarOwned, icsCalendar, and icsDWPHost (if in the LDAP CLD setup). A Calendar Server administrator will not be able to create calendars on the user’s behalf. These attributes are restored in the user’s LDAP entry when: The user logs back into Calendar Server, or The Calendar Server administrator issues a csuser enable command for the user (although in this case, the icsDWPHost attribute is not restored).

Renaming Users

If one or more user IDs need to be changed, run the csrename utility. This utility performs the following steps:

Converts the user IDs in the Calendar Server LDAP attributes (the ones with the ics prefix). The LDAP directory is updated in place.

Renames the users in events and tasks on the Calendar Server database files. It writes the new database to a destination directory. Existing database files are not modified.



Note	Be aware that changing even one user ID causes the whole database to be rewritten. So this is a “costly” utility to run.

Managing LDAP Attributes

To manage the LDAP attributes used by Calendar Server, use the csattribute utility.



Note	If your site is using the LDAP CLD plug-in, do not attempt to move a user’s calendars from one back-end host to another by merely changing the value of icsDWPHost, using csattribute. Modifying icsDWPHost does not cause the calendar to be moved to the new back-end host. For more information, see Moving a Calendar to a Different Back-End Server.

Listing LDAP Attributes

To list LDAP attributes for a user or resource, use the csattribute utility add command. For example, to list the LDAP attributes for the user TChang:

Adding an LDAP Attribute

To add an attribute to the LDAP server, use the csattribute utility add command. For example, to add the LDAP attribute icsCalendar with the value Conference_Schedule to the user TChang:

Deleting an LDAP Attribute

To delete an attribute to the LDAP server, use the csattribute utility delete command. For example, to delete the LDAP attribute icsCalendar from TChang:

Previous Contents Index Next
Sun Java System Calendar Server Administration Guide