test

Sun Java System Calendar Server 6.3 Administration Guide

14.5 Administering Existing Users

This section contains conceptual information and instructions for administering user entries in an LDAP database. It does not include creating user entries. For information on creating user entries, see14.1 Creating Calendar User LDAP Entries.

Administer users with either the Delegated Administrator Utility or Console for Schema version 2 LDAP user entries, or the csuser utility for Schema version 1 LDAP user entries.

The administrative tasks covered in this section are the following:

14.5.1 Displaying Calendar User Information

This section shows two command examples using the Calendar Server utilities command, csuser list, to obtain a list of all calendar users, or to display a particular user's calendar attributes (from the LDAP user entry).

This section contains the following topics:

14.5.1.1 To Display All Users Enabled for Calendaring

To display all users enabled for calendaring, issue the following command-line utility:

csuser list

14.5.1.2 To Display a Particular User's Calendar Attributes

To display all of the calendar attributes for a single user, issue the following command-line utility:

csuser -v list fully-qualified-user-name

For example, if the user is jsmith who belongs in the sesta.com domain, the command-line would be the following:

csuser -v list jsmith@sesta.com

14.5.2 Disabling a Calendar User

The purpose of disabling a user is to prevent the user from logging into Calendar Server. This is handled differently depending on which user management tool you used to create the user. Users created in the Delegated Administrator Console should be administered using it also. Likewise, if you assigned calendar service to the user with Delegated Administrator Utility, use it to remove the service. Each handles the situation a bit differently.

This section contains the following topics:

14.5.2.1 To Disable a User with Delegated Administrator Console

In the Delegated Administrator Console, it is not possible to merely temporarily inactivate a user. You must remove calendar services from the user. To do this, select the user from the User List page. In the Properties for this user, delete the service package with calendar service in it. This disables the user for calendar, including setting the user's icsStatus to inactive.

Note –

If the package also contains other services, you will have to reassign those services using another package that does not contain calendar.

14.5.2.2 To Disable a User with Delegated Administrator Utility (commadmin user delete)

To prevent a user from accessing calendar services, remove the service from the user’s LDAP entry, as shown in the example that follows:

commadmin user delete jsmith -S cal

This removes calendar service from the user without completely removing the LDAP entry. In addition, this command changes the user's icsStatus to inactive.

14.5.2.3 To Disable a User with Calendar Server Utilities (csuser disable)

The disable command prohibits a user from accessing calendar data, but it does not remove calendar service from the user’s LDAP entry or the Calendar Server database. The utility signals the user being disabled by adding icsAllowedServiceAccess="http" to the user LDAP entry.

For example, to disable jsmith from accessing Calendar Server:

csuser disable jsmith

If jsmith is currently logged into Calendar Server, jsmith retains access to calendar data until he logs off.

14.5.2.4 To Remove Calendar Service from a User with Calendar Server Utilities

To remove calendar service from a user, use the csuser utility reset command.

For example, to remove calendar service from jsmith:

csuser reset jsmith

Doing this removes all of the calendar attributes from the user’s LDAP entry, including icsCalendarUser (object class), icsSubscribed, icsCalendarOwned, icsCalendar, and icsDWPHost (if using LDAP CLD). A Calendar Server administrator will not be able to create calendars on the user’s behalf.

Note –

Calendar Service is restored to the user when one of the following happens:

14.5.3 Enabling a Calendar User

This section contains information about how to enable calendar service for a user.

When users are created, they are normally enabled for calendar service. However, it is possible that a user can be disabled. To re-enable the user for calendar services, you must use one of the methods in this section.

Caution – Caution –

Enabling a user is implemented slightly differently, between the Delegated Administrator Console and the Utility. Thus, you should use the same tool for both enabling and disabling a user. Do not disable using one tool and re-enable using another.

This section covers the following methods of enabling a user:

14.5.3.1 To Enable a User with Delegated Administrator Console

You can not disable a user from the Console. You can remove calendar service and then re-add them. To re-add the service, select the user from the User List page and use the Assign Service Package wizard to add the calendar service package to the user's LDAP entry. The user is automatically enabled.

Note –

This is the same procedure used to add calendar service (14.5.4 Adding Calendar Service to a User).

14.5.3.2 To Enable a User with Delegated Administrator Utility

Delegated Administrator Utility can enable a user with either one of the following choices:

Caution – Caution –

Be sure to use the same method to enable and disable a user. If you tried to enable a user with Delegated Administrator Console, after having disabled the user with Delegated Administrator Utility (changing the icsStatus only), the system will not be able to add service since the user already has service and the user will still be disabled.

14.5.3.3 To Re-Enable a User with Calendar Server Utilities

To re-enable a user for calendar service, use csuser enable to remove icsAllowedServiceAccess="http" from the user's LDAP record.

14.5.4 Adding Calendar Service to a User

It is not necessary to add calendar service to a user created with the old (Schema version 1) Calendar Server utilities. However, with (Schema version 2) Delegated Administrator, calendar service can be added and removed from a user's LDAP entry.

To add calendar service to an existing user, use one of the following tools:

14.5.4.1 To Add Calendar Service to a User with Delegated Administrator Console

You can add calendar services to both a new user and an existing user:

14.5.4.2 To Add Calendar Service to a User with Delegated Administrator (commadmin user create)

When creating a new user, add calendar services as illustrated in the example that follows:

commadmin user create jsmith -S cal

If you did not add calendar services when the user was created, you can add calendar services to the user later, using a modify command, as illustrated in the following example:

commadmin user modify jsmith -S cal

14.5.4.3 To Add Calendar Service with Calendar Server Utilities

If you used csuser create when you created the user entry, the utility gives calendar service to the user by adding icsCalendarUser and its attributes to the user LDAP entry.

14.5.5 Deleting Calendar Service from a User LDAP Entry

One way to deny calendar service to a user is to remove the service from the user entry. Another way is to disable the user temporarily. These are covered in the earlier section titled 14.5.2 Disabling a Calendar User.

14.5.6 Setting Up Email Aliases for a Calendar User

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

You can add the attribute in the following three ways:

, using commadmin user modify -A or by directly updating LDAP with ldapmodify.

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 documentation is available on this at: http://docs.sun.com/coll/1312.2.

ProcedureTo Set Up Email Aliases with Delegated Administrator Console

  1. Choose the organization where the user resides.

  2. Search for the user.

  3. Display the user's properties by clicking the user's name.

  4. Edit the Mail Services Details to add aliases.

See Also

The Delegated Administrator online help.

14.5.6.1 To Set Up Email Aliases with Delegated Administrator Utility

Email aliases can be set up for calendar users, just like messaging users, by adding mailalternateaddress to the user's LDAP entry. To add the attribute using Delegated Administration Utility, use commadmin user modify -A mailalternateaddress:value.

14.5.6.2 To Set Up Email Aliases with Calendar Server Utility csattribute

To add email aliases to a user, use the csattribute add -a command to add mailalternateaddress attributes to the user entry.

For example, to add two aliases for a user named John Smith with these values:

The commands would look like the following examples:

csattribute -a mailalternateaddress=johns@sesta.com add johnsmith@sesta.com

csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith@sesta.com

14.5.7 Verifying that a User has Calendar Service

This section provides instructions for verifying calendar service.

Use the following tools to verify that a user has calendar service.

14.5.7.1 To Check if a User has Calendar Service with Delegated Administrator Console

If there is a Calendar Service Details page, then they have calendar services. Or, look in the service package details to see what kinds of services are listed.

14.5.7.2 To Check if a User has Calendar Service with Delegated Administrator Utility

Use the following command to list all the directory properties associated with the user:

commadmin user search

14.5.7.3 To Check if a User has Calendar Service with Calendar Server Utility csuser

Use the following command to check if the user is enabled for calendar service:

csuser check

14.5.8 Deleting Users from the LDAP Database

Use either Delegated Administrator or the Calendar Server Utilities to delete a user from LDAP.

Use one of the two methods that follow to delete users from the LDAP database:

Caution – Caution –

There is no undelete command.

Once users in a domain are deleted using Delegated Administrator, they must be purged and re-added from scratch. User names can not be reused until the purge happens.

ProcedureDeleting Users in Schema Version 2 Using Delegated Administrator

You can mark users for deletion with either Delegated Administrator interface. However you can not actually remove users from LDAP (purge) using the Delegated Administrator Console. You must use the Delegated Administrator Utility for that. The following task lists the steps for deleting a user from LDAP. The user is not actually removed from LDAP until the last step is complete.

  1. Mark a user entry for deletion.

    For Delegated Administrator Console: Select the users to delete in the User List page and click Delete.

    For Delegated Administrator Utility: Use the commadmin user delete command. For example: 

    commadmin user delete -D chris -n siroe.com 
-w bolton -l jsmith

    In both cases the icsStatus attribute in the user LDAP entry is changed from active to deleted.

  2. Use the Calendar Server Utility csclean to remove all calendars belonging to all deleted users in one or all domains, as shown in the following example:

    csclean clean “*”

    Or to remove calendars belonging to all deleted users in one domain, specify the actual domain, as shown in the following example: csclean clean sesta.com

    Tip –

    If you inadvertently purge the users from LDAP before deleting the users' calendars, you can remove them later using the cscal utility, as described in 15.6 Managing User Calendars.

  3. Purge the domain of all users marked for deletion, using Delegated Administrator Utility command commadmin domain purge.

    For example:

    commadmin domain purge -D chris -d sesta.com -n siroe.com -w bolton

    In this example, all users in sesta.com that are marked as deleted will be purged, that is, permanently removed.

    Tip –

    Run this utility manually from time to time to clean up your LDAP directory. For more information about this command, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

14.5.8.1 Deleting Users in a Schema Version 1 Environment

To remove the specified user’s LDAP entry and the user’s default calendar, use the Calendar Server utility csuser with the delete command.

For example, to delete the LDAP entry and the default calendar for user jsmith use the following command:

csuser delete jsmith

If you wish to remove the other calendars belonging to this user, you must use cscal as described in 15.6 Managing User Calendars.

14.5.9 Renaming Calendar Users

If one or more user ID's need to be changed, run the csrename utility.

This utility performs the following steps:

Note –

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

For further information on the csrename utility, see Appendix D, Calendar Server Command-Line Utilities Reference.

14.5.10 Turning the Publicly Writable Calendars Feature Off

Publicly Writable Calendars is a Calendar Server feature. You can turn this feature on or off. It is enabled by default. The following task shows how to edit the configuration file to change the setting.

With this feature enabled, calendars can be scheduled (written to) when an invitation is generated. The event will automatically be added to the attendees' calendars.

With this feature disabled, calendar owners will get an email notification only when an invitation is generated. The event will not be automatically added to the attendees' calendars. Only the owners are allowed to add events and tasks to the calendar.

ProcedureTo Disable Users from Having Publicly Writable Calendars

  1. Log in as an administrator with configuration privileges.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit the following ics.conf parameter as shown in the following table:

    Parameter  

    Description and Default Value  

    service.wcap.

    allowpublicwritablecalendars

    Enables users to have publicly writable calendars. This is enabled by default (set to “yes”).

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal