Calendar Server uses access control lists (ACLs) to determine access control for calendars, calendar properties, and calendar components such as events and todos (tasks). An ACL consists of one or more access control entries (ACE's), which are strings that collectively apply to the same calendar or component Each ACE in an ACL must be separated by a semicolon.
ACE strings are case insensitive.
For example:
jsmith^c^wd^g consists of a single ACE.
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g consists of three ACE's.
An ACE consists of the following elements, with each element separated by a caret (^):
Who - The individual, user, domain, or type of user who the ACE applies to.
What - The target being accessed, such as a calendar or a calendar component such as an event, todo (task), or calendar property.
How - The type of access control rights permitted, such as read, write, or delete.
Grant - A specific access control right that is either granted or denied.
For example, in the ACE jsmith^c^wd^g:
jsmith is the Who element, indicating who the ACE applies to.
c is the What element, indicating what is being accessed (only the calendar components).
wd is the How element, indicating which access rights are to be granted or denied (write and delete).
g is the Grant element, indicating that the specified access rights, write and delete, for the calendar components are granted to jsmith.
The Who element is the principal value for an ACE and indicates who the ACE applies to, such an individual user, domain, or specific type of user.
Who is also called the Universal Principal Name (UPN). The UPN for a user is the user’s login name combined with the user’s domain. For example, user bill in domain sesta.com has the UPN bill@sesta.com.
Table 1–2 “Who” Formats for Access Control Entry (ACE) Strings
The What element specifies the target being accessed, such as a calendar, calendar component (event or task), or calendar property.
Table 1–3 “What” Values for Access Control Entry (ACE) Strings
Value |
Description |
|
---|---|---|
|
Specifies calendar components such as events and tasks |
|
|
Specifies calendar properties such as name, description, owners, and so forth |
|
|
Specifies an entire calendar (all), including both components and properties |
The How element specifies the type of access control rights permitted, such as read, write, or delete.
Table 1–4 “How” Types for Access Control Entry (ACE) Strings
Type |
Description |
---|---|
r |
Read access. |
w |
Write access, including adding new items and modifying existing items. |
d |
Delete access. |
s |
Schedule (invite) access. Requests can be made, replies will be accepted, and other ITIP scheduling interactions will be honored. |
f |
Free/busy (availability) access only. Free/busy access means that a user can see scheduled time on a calendar, but is not allowed to see the event details. Instead, only the words “Not Available” appear by a scheduled time block. Blocks of time without any scheduled events are listed with the word “Available” next to them. |
l |
Lookup access for a domain. |
e |
Act on behalf of for reply access. This type grants a user the right to accept or decline invitations on behalf of the calendar’s primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar. |
i |
Act on behalf of for invite access. This type grants a user the right to create and modify components in which other attendees have been invited on behalf of the calendar's primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar. |
c |
Act on behalf of for cancel access. This type grants a user the right to cancel components to which attendees have been invited on behalf of the calendar's primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar. |
z |
Self-administrating access - the authenticated user is granted the ability to add or remove an Access Control Entry. Users with this privilege can add and remove privileges for themselves. For example, UserA may not have write access to UserB’s calendar, but UserA has been granted self-administrating access to UserB’s calendar. Therefore, UserA can add an Access Control Entry that grants himself write access to UserB’s calendar. Note: This privilege does not allow UserA to grant other users access to UserB’s calendar. For example, the self-administrating privilege does not allow UserA to grant UserC access to UserB’s calendar. |
The Grant element specifies whether to grant or deny access for a specified access type, such as d (delete) or r (read).
Table 1–5 Grant Values for Access Control Entry (ACE) Strings
Value |
Description |
---|---|
g |
Grant the specific access control right. |
d |
Deny the specific access control right. |
The following examples show the use of ACE's:
Grant the user ID jsmith read access to the entire calendar, including both components and properties:
jsmith^a^r^g
Grant jsmith write and delete access to components only:
jsmith^c^wd^g
Grant all users in the sesta.com domain privileges to schedule, availability, and read access to components only:
@sesta.com^c^sfr^g
Grant all owners write and delete access to components only:
@@o^c^wd^g
Deny jsmith all access to calendar data:
jsmith^a^sfdwr^d
Grant all owners read, schedule, and availability access to the entire calendar, including both components and properties:
@@o^a^rsf^g
Grant read access to all users:
@^a^r^g
When the Calendar Server reads an ACL, it uses the first ACE it encounters that either grants or denies access to the target. Thus, the ordering of an ACL is significant, and ACE strings should be ordered such that the more specific ones appear before the more general ones.
For example, suppose the first ACE in an ACL for the calendar jsmith:sports grants read access to all users. Then, Calendar Server encounters a second ACE that denies bjones read access to this calendar. In this case, Calendar Server grants bjones read access to this calendar and ignores the second ACE because it is a conflict. Therefore, to ensure that an access right for a specific user such as bjones is honored, the ACE for bjones should be positioned in the ACL before more global entries such as an ACE that applies to all users of a calendar.