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.