This chapter describes how to use Delegated Administrator and the Calendar Server utilities to manage users, groups, and resources.
This chapter contains the following sections:
This section contains instructions for creating new user entries.
This section contains the following topics:
14.1.1 To Create New Calendar Users in Schema Version 2 Mode
14.1.2 To Create New Calendar Users For Schema Version 1 Mode
This section describes how to create new calendar users for Schema version 2 LDAP entries.
You can use either the Delegated Administrator Console or Utility:
Delegated Administrator Console
In the Delegated Administrator Console, use the Create New User wizard. (Click New in the User List page for the organization where the user is to reside.) For more information, see the Delegated Administrator Console online help.
Delegated Administrator Utility
Use the commadmin utility user create command. For example, to add user jdoe in the sesta.com domain:
commadmin user create -D calmaster -F John -n sesta.com -k hosted -l jdoe -w calmasterpassword -W jdoepassword -L Doe -S cal -B red.sesta.com -E jdoe@sesta.com
For details on all the available options for the commadmin utility, refer to the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide
Use the csuser utility. For example, to add user jdoe in the sesta.com domain:
csuser -m jdoe@sesta.com -d sesta.com create jdoe
This section describes how to create new group LDAP entries
This section contains the following instructions:
14.2.1 To Create New Calendar Groups for Schema Version 2 Mode
14.2.2 To Create New Calendar Groups for Schema Version 1 Mode
Groups are named lists of users, resources, or other groups (nested groups). Groups can be either static or dynamic.
Groups do not contain both static and dynamic members. If an empty group is created, the default is a static group.
You can use one of the following tools:
Delegated Administrator Console — From the Groups page, click New. The Create New Group wizard appears. The Calendar Service Details screen follows the Mail Service Details screen. You can also assign a service package to the group on the Calendar Service Details screen.
For more information on the Console, see the Delegated Administrator Console online help.
Delegated Administrator Utility — Use commadmin group create.
For example:
commadmin group create -D chris -n sesta.com -w bolton -G testgroup -d sesta.com -m lorca@sesta.com -S mail -M achiko@varrius.com
For details on all the available options for the commadmin utility, refer to the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide
Add the group LDAP entry directly. Use the Directory Server LDAP commands found in Sun ONE Directory Server Resource Kit 5.2 Tools Reference.
The group LDAP entry should include the icsCalendarGroup object class, which is an extension of the GroupofUniqueNames object class. The following are attributes that can be included:
Attribute |
Description |
---|---|
groupid |
The is the only required attribute for a group. It is the unique identifier for the group, similar to the uid for a user. |
icsSecondaryowners |
Co-owners of the group. |
icsDefaultacl |
ACL string for the new group calendar. |
icsCalendar |
The calid of the default calendar for this group. It is not required for a group to have a default calendar. |
icsStatus |
The status of the group calendar. Possible values are: active, inactive, deleted. |
icsTimezone |
Time zone for the group. |
icsDWPHost |
The name of the back-end host where the default calendar resides. |
icsDoublebooking |
Whether or not the default calendar allows multiple events to be scheduled in the same time period. This overrides the domain level preference, bit 15 of icsAllowRights. See To Configure Calendar Server for Groups for domain level defaults for groups. |
icsAutoaccept |
Whether or not invitations will automatically be accepted for the default calendar. |
|
The email address for this group. |
owner |
Distinguished Name for the owner's LDAP entry of the group. Must be single valued. |
The primary owner is specified by the attribute owner from the GroupOfUniqueNames object class.
For example, a group LDAP entry might contain:
dn: groupid=mygroup, ou=group, o=sesta.com objectclass:groupofuniquenames objectclass:icsCalendarGroup groupid:mygroup owner:uid=jdoe, ou=people, o=sesta.com icsSecondaryowners:uid=pfox, ou=people, o=sesta.com icsStatus:active uniqueMember: uid=wsmith, ou=people, o=sesta.com
For more information about object classes and attributes, see the Sun Java System Communications Services 6 2005Q4 Schema Reference.
This section describes how to create new resources.
Use one of the following ways to create a calendar resource entry:
14.3.1 To Create New Calendar Resources for Schema Version 2 Mode
14.3.2 To Create New Calendar Resources for Schema Version 1
This section contains instructions for creating new resource LDAP entries in Schema version 2 mode.
You can use either the Delegated Administrator Console or Utility:
Delegated Administrator Console
In the Delegated Administrator Console, use the Create New Resource wizard. (Click New in the Calendar Resources tab for the organization where the resource is to reside.) For more information, see the Delegated Administrator Console online help.
Delegated Administrator Utility
Use the commadmin utility rescource create command to create an LDAP entry. For example, to add the conference room Conference_Room_100, use the following command:
commadmin resource create -D calmaster -w calmasterpassword -n sesta.com -c room100 -N Conference_Room_100
You must then use csresource to create the actual resource calendar. For information on how to create a resource calendar, see 15.5 Creating Calendars
For details on all the available options for the commadmin utility, refer to the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide
Use the csresource utility to create both the LDAP entry and the resource calendar. For example, to add a projector, p101, use the following command:
csresource -m p101@siroe.com -c p101 create Projector_101
For more information on csresource, see the D.15 csresource.
This section contains conceptual information and instructions for enabling LDAP entries for mail service.
This section covers the following topics:
14.4.1 Overview of Adding Mail Service to Calendar Server LDAP entries
14.4.2 To Check if the mail Attribute Exists in the LDAP Entry
Calendar Server requires users, groups and resources to have the mail attribute, which contains the email address of the user, group or resource. This enables people to search for calendars using either an email address or a calid. When you create new users with Delegated Administrator, it adds the mail attribute automatically. This happens even if the user has not been assigned mail service. However, if your users and resources were created in a version of Calendar Server when the mail attribute was not required, you might have to add the mail attribute to your existing user and resource LDAP entries.
Adding the mail attribute does not enable email notifications for user calendars.
Calendar Server does not support email notifications for group, or resource calendars.
To enable email notification for user calendars, add the following two attributes to the user’s LDAP entry:
icsExtendedUserPrefs:ceNotifyEnable=1
icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com
If you do not know if your users, groups and resources have the mail attribute, for Schema version 2 environments, use Delegated Administrator to check for mail services.
For Schema version 1 environments, use the csattribute list command with the -v (verbose) option.
For example, to check if the conference room resource Room100 has the mail attribute, you would issue the following command:
csattribute -v list Room100
The output tells if the mail attribute is present:
cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com
If the mailattribute exists, you do not have to add it. If the attribute does not exist, then add it as shown in the section that follows.
If you are converting existing LDAP entries to calendar enabled entries, you must add the mail attribute to each user, group and resource LDAP entry that does not contain it.
To add the mail attribute to existing users, groups and resources, use one of the following methods:
Use Delegated Administrator Utility for a Schema version 2 Environment.
Use the commadmin user|resource|group modify -A option.
For example: commadmin group modify -A +mail:jdoe@sesta.com
Use the Calendar Server D.3 csattribute utility for a Schema version 1 environment.
The following example adds the LDAP mail attribute for an existing conference room named Room100 on the sesta.com server:
csattribute -a mail=Room100@sesta.com add Room100
Use ldapmodify to add the attribute directly to the LDAP entries for either Schema version.
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:
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:
To display all users enabled for calendaring, issue the following command-line utility:
csuser list
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
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
14.5.2.2 To Disable a User with Delegated Administrator Utility (commadmin user delete)
14.5.2.3 To Disable a User with Calendar Server Utilities (csuser disable)
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.
If the package also contains other services, you will have to reassign those services using another package that does not contain calendar.
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.
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.
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.
Calendar Service is restored to the user when one of the following happens:
The user logs back into Calendar Server (with autoprovisioning turned on).
The Calendar Server administrator issues a csuser enable command. In this case, the icsDWPHost attribute is not restored with the command. You must add it separately.
The Calendar Server administrator specifically adds the object class and attributes to the user LDAP entry.
You have recently migrated to Schema version 2 and use the Delegated Administrator to add calendar service.
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.
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
14.5.3.2 To Enable a User with Delegated Administrator Utility
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.
This is the same procedure used to add calendar service (14.5.4 Adding Calendar Service to a User).
Delegated Administrator Utility can enable a user with either one of the following choices:
Enabling the user by changing the icsStatus to active.
commadmin user modify -A icsStatus:active to enable the user.
Adding the calendar service to the user LDAP entry.
commadmin user modify -S cal
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.
To re-enable a user for calendar service, use csuser enable to remove icsAllowedServiceAccess="http" from the user's LDAP record.
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 (for Schema version 2)
14.5.4.2 To Add Calendar Service to a User with Delegated Administrator (commadmin user create)(for Schema version 2)
14.5.4.3 To Add Calendar Service with Calendar Server Utilities (for Schema version 1).
You can add calendar services to both a new user and an existing user:
When a new user is created, using the New User wizard, it assigns the user a service package that includes calendar service. The user is automatically enabled.
For an existing user, select the user from the User List page and use the Assign Service Package wizard to select a service package with calendar service. The user is automatically enabled.
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
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.
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.
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:
To Set Up Email Aliases with Delegated Administrator Console
14.5.6.1 To Set Up Email Aliases with Delegated Administrator Utility
14.5.6.2 To Set Up Email Aliases with Calendar Server Utility csattribute
, using commadmin user modify -A or by directly updating LDAP with ldapmodify.
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.
Choose the organization where the user resides.
Search for the user.
Display the user's properties by clicking the user's name.
Edit the Mail Services Details to add aliases.
The Delegated Administrator online help.
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.
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:
With a mail attribute of: johnsmith@sesta.com
Email aliases: johns@sesta.com and jsmith@sesta.com
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
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
14.5.7.2 To Check if a User has Calendar Service with Delegated Administrator Utility
14.5.7.3 To Check if a User has Calendar Service with Calendar Server Utility csuser
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.
Use the following command to list all the directory properties associated with the user:
commadmin user search
Use the following command to check if the user is enabled for calendar service:
csuser check
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:
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.
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.
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.
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
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.
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.
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.
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.
If one or more user ID's need to be changed, run the csrename utility.
This utility performs the following steps:
Converts the user ID's 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.
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.
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.
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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”). |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
This section contains conceptual information and instructions on administering calendar resources.
After your resources are added, you can administer them using Delegated Administrator or csresource.
This section contains the following topics:
This section contains instructions for retrieving resource LDAP information.
You can retrieve resource properties from the LDAP resource entry with one of three tools:
To Retrieve Resource Information Using Delegated Administrator Console
14.6.1.1 To Retrieve Resource Information Using Delegated Administrator Utility
In the Delegated Administrator Console, click the Calendar Resources tab.
Use the Search Results drop-down box to select one of the following options:
Search Calendar Resource by Resource ID
Search Calendar Resource by Calendar Resource Name
Type the value you want to search for.
Click Search.
Use the commadmin resource search command to retrieve LDAP information for a resource.
For example, to search for the resource CF101 in the sesta.com domain, use the following command:
commadmin resource search -D serviceadmin -w serviceadmin -n sesta.com \s -d sesta.com -u CF101
You can retrieve the LDAP entry information for a resource or for all resources using the csresource utility.
Change to the sbin directory.
Use the csresource list command to list one or all resources.
For example, list all the information about all the resources:
./csresource -v list
Or, list all the information about a specific resource, CF101:
./csresource
Change to the sbin directory.
Use the csresource enable command to enable one or more resources.
For example, to enable the ConfRm12 resource:
./csresource -v enable ConfRm12
Change to the sbin directory.
Use the csresource disable command to disable one or more resources. For example, to disable the ConfRm12 resource:
./csresource -v disable ConfRm12
Change to the sbin directory.
Use the csresource delete command to delete one or more resources. For example, to delete the ConfRm12 resource:
./csresource -v delete ConfRm12
This section contains directions for setting up a bitbucket channel for both Messaging Server and Sendmail. The bitbucket channel is a way to discard 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.
This section contains the following procedures:
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
Manage LDAP attributes used by Calendar Server, with the D.3 csattribute utility, or ldapmodify. Attributes can be listed, added, or deleted with csattribute. To modify an attribute, use ldapmodify.
This section contains the following topics:
Log in as the user or group under which Calendar Server is running (such as icsuser and icsgroup) that was specified during installation, or as root
Change to the sbin directory.
Use the csattribute list command to list the attributes for a user or a resource. For example, to list the attributes for tchang@sesta.com, issue the following command:
./csattribute -t user -d sesta.com list tchang
Log in as the user or group under which Calendar Server is running (such as icsuser and icsgroup) that was specified during installation, or as root
If you want this attribute change to be recognized immediately, stop Calendar Server. Otherwise, you do not have to stop Calendar Server.
Change to the sbin directory.
Use the csattribute add command to add an attribute to a user or a resource. For example, to add the LDAP attribute icsCalendar with the value Conference_Schedule to the user tchang:
./csattribute -a icsCalendar=Conference_Schedule add tchang@sesta.com
Log in as the user or group under which Calendar Server is running (such as icsuser and icsgroup) that was specified during installation, or as root
If you want this attribute change to be recognized immediately, stop Calendar Server. Otherwise, you do not have to stop Calendar Server.
Change to the sbin directory.
Use the csattribute delete command to delete an attribute from a user or a resource. For example, to delete the LDAP attribute icsCalendar with the value Conference_Schedule from the user tchang:
./csattribute -a icsCalendar=Conference_Schedule -t user -d sesta.com delete tchang
To modify an LDAP entry attribute, use ldapmodify. For example, to change the status of user with uid=tchang, use ldapmodify as shown:
dn:uid=tchang,ou=people,o=sesta.com changetype: modify add: objectclass objectClass: icsCalendarUser add: icsStatus icsStatus: active |
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 changing the value of icsDWPHost, using csattribute. Modifying icsDWPHost does not cause the calendar to be moved to the new back-end host. For instruction on how to move a calendar from one back-end server to another, see 15.6 Managing User Calendars.