We are a franchise organization and all of our locations, including the corporate office, share a domain for email. We've implemented Zimbra for the corporate office and are now looking to offer Zimbra to our franchisees. The problem, however, is how to keep everything compartmentalized - resources in particular.
For example, an employee at a franchise location shouldn't be able to schedule a meeting in a conference room at the corporate headquarters. I thought Class of Service would be the answer to this one, but if I have a user in one COS, and a resource in another COS, the user can still see free/busy info on the resource and schedule its use. This brings up another question: What does COS on a resource actually do?
How have other administrators solved this issue?
Compartmentalized groups or locations sharing a domain
Compartmentalized groups or locations sharing a domain
5.0.7: Bug 22913 - Access control for free busy and resources (ie permission to invite)
ZimbraServer/docs/accesscontrol.txt
OVERVIEW
========
Currently, we have "mail object" based access control mechanism in that
ACLs are generally associated with a single object in a user's Mailbox,
for example, a folder or a tag. The ACLs for mail object based access
controls are persisted in the user's database, in the METADATA column on the
MAIL_ITEM row for the folder or tag. ZimbraServer/docs/acl.txt describes
"mail object" based access controls.
In addition to the above access control scheme, it is required that we
support access control on the account level, where permissions are
granted on the account level, instead of on individual folders or tags.
Implementation of account based access controls is not changing any aspect
of "mail object" based access controls. However many of the terminologies
and concepts are shared between the two.
This document describes the account based access control mechanism.
On a side note, the role based delegated admin feature in GnR will be built
on the same model.
RIGHTS
======
Unlike mail object based access controls, rights for account based controls
are defined on a "higher", or "functionality" level. For example, instead
of the generic combination of "read', 'write" rights that can be applied to
all mail objects, rights for account based access controls are like
"viewFreeBusy", "invite", ...
Currently, the following rights are supported:
- invite
- viewFreeBusy
zmmailbox helpPermissions command describes each rights in more details.
NEGATIVE RIGHTS
===============
Negative right are to specifically deny certain privileges to the "grantee".
Negative rights will take precedence over positive rights.
For example, if you granted "no invite" to user A, then invites from user A
would not be able to automatically book the target account's calendar for the
appointment. Regardless of what other grants for the same right is applied to
user A(e.g. allow all authed users).
GRANTEES
========
Like mail object based access controls, to avoid support calls:
(1) a user always has full, irrevocable rights to their own mailbox.
and
(2) administrators are allowed full access to everything on the system,
until we have a full-featured role based delegated admin implementation.
Rights can be granted(allowed or denied) to other principals.
The type of supported grantees are:
user - a Zimbra user
group - a Zimbra group(distribution list)
all-authed - all authed Zimbra usres
public - the public
CONFLICTING GRANTEES
====================
When more than one ACEs of an ACL on the same right match a grantee and all ACEs
don't agree on the same allow/deny for the right, the ACE with the most specific
match takes precedence; and if all matching ACEs are equally related to the grantee,
the negative ACE takes precedence.
example 1:
- ACL has:
. allow user A for right R
. deny group G for right R
- user A is in group G
=> user A will be allowed for right R, because user match is more specific than group match.
example 2:
- ACL has:
. allow group G1 for right R
. deny group G2 for right R
- group G2 is a member of group G1
- user A is a member of group G2
=> user A will be denied for right R, because G2 is a more specific match than G1.
example 3:
- ACL has:
. allow group G1 for right R
. deny group G2 for right R
- group G1 and G2 are not member of each other
- user A is in both group G1 and group G2
=> user A will be denied, because negative ACE takes precedence.
If multiple ACEs conflict for a right for the same grantee, this is a wrong setting, which
should not happen if all modification to ACLs are done via the supported granting/revoking
interfaces: SOAP and zmmailbox. If for any reason such ACL does exist (e.g.
via ldapmodify, or zmprov ma command(should we make zimberaACE immutable so
it cannot be modified by zmprov?)), the result is **unexpected**, depending on
which ACE is encountered first when we iterate through the ACL. We could've
spent more cycles detecting such settings and honor the negative ACE if there
is one, but currently the implementation choice is not to do so.
e.g. - ACL has:
. allow user A for right R
. deny user A for right R
=> user A could be allowed or denied for right R, randomly.
ACL STORAGE AND SERIALIZATION FORMAT
====================================
ACLs are persisted in LDAP in the multi-valued "zimbraACE" attribute on the
target LDAP entry. ACE stands for "access control entry", multiple ACEs makes
an ACL(access control list).
ACEs are serialized in LDAP in the following format:
[-]
grantee: For user and group grantees, zimbraId of the account/distribution list
For all-authed and public grantees, pseudo UUID recognized by the code.
grantee-type: usr | grp | all | pub
right: one of the supported right.
if a '-' (minus sign) is prepended to the right, it means the right is
specifically denied.
e.g. fe0e1a88-e6e3-4fe1-b608-3ab6ce50351f grp -viewFreeBusy
fd6227f2-87e6-4453-9ccc-16853a6f8d27 usr viewFreeBusy
00000000-0000-0000-0000-000000000000 all viewFreeBusy
99999999-9999-9999-9999-999999999999 pub invite
Note: zimbraACE should NOT be directly modified via zmprov or any LDAP tools.
They should only be modified via zmmailbox commands. See GRANTING TOOLS below.
GRANTING TOOLS
==============
Before WEB UI is available for granting, revoking, viewing rights, zmmailbox is the sole
tool that should be used for those tasks.
zmmailbox commands:
1. List all permission related commands
command: help permission
scope: any
example:
mbox> help permission
getPermission(gp) [opts] [right1 [right2...]]
-v/--verbose verbose output
grantPermission(grp) {account {name}|group {name}|all|public {[-]permission}}
listPermission(lp) [opts]
-v/--verbose verbose output
revokePermission(rvp) {account {name}|group {name}|all|public {[-]permission}}
2. List and describe all permissions that can be granted
command: listPermission(lp) [opts]
-v/--verbose verbose output
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> lp -v
invite: automatically add meeting invites from grantee to the target's calendar
e.g. (1) When user Y is invited to a meeting, an appt is added to his calendar
automatically(tentatively) only if invite is from A, B, C or anyone in group G.
(2) Conf room Y can only be booked by users A, B, C and group G.
viewFreeBusy: view free/busy
e.g. Free/busy for Y can only be seen by users A, B, C and group G.
3. Get rights currently granted.
command: getPermission(gp) [opts] [right1 [right2...]]
-v/--verbose verbose output
Optional right(s) can be specified to get only ACEs for those rights.
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite all
-viewFreeBusy account user2@example.com
-viewFreeBusy group groupX@example.com
viewFreeBusy all
viewFreeBusy public
mbox user1@example.com> gp invite
Permission Type Display
---------------- -------- -------
invite all
Note:
- grants are sorted by Permission, then type(from the most specific to the least specific:
account, group, all, public), then grantee display name.
- To be consistent with the modifyFolderGrant(mfg) command, which is for mail object based permissions,
grantee types are displayed as account(for user grantee), group(for group grantee), all(for all-authed
grantee), and public(for public grantee).
4. Grant(allow or deny) a right to a grantee or a group of grantee.
To deny a right, put a '-' in front of the right.
command: grantPermission(grp) {account {name}|group {name}|all|public {[-]right}}
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> grp account user3 invite
granted:
account user3@example.com invite
mbox user1@example.com> grp group group1@foo.com -viewFreeBusy
granted:
group group1@foo.com -viewFreeBusy
mbox user1@example.com> grp group group2 invite
granted:
group group2@example.com invite
mbox user1@example.com> grp all viewFreeBusy
granted:
all viewFreeBusy
mbox user1@example.com> grp public -viewFreeBusy
granted:
public -viewFreeBusy
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite account user3@example.com
invite group group2@example.com
-viewFreeBusy group group1@foo.com
-viewFreeBusy public
viewFreeBusy all
Note:
(1) if domain is not given for account or group grantee, the domain of the selected
mailbox will be used.
(2) if a grantee currently has a grant(positive or negative) for a right, granting
to the same grantee with a different privilege overwrite the grant. For example,
if user A currently is allowed the right to invite, "grp account A -invite" will
change the grant(i.e. ACE) from allowed to denied.
(3) to complete remove a grant(i.e. an ACE) from a grantee, use the revokePermission(rvp)
command, see 5. below.
5. Revoke a right previously granted to a grantee or a group of grantees.
To revoke a denied right, put a '-' in front of the right.
command: revokePermission(rvp) {account {name}|group {name}|all|public {[-]right}}
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite account user3@example.com
invite group group2@example.com
-viewFreeBusy group group1@foo.com
-viewFreeBusy public
viewFreeBusy all
mbox user1@example.com> rvp group group1@foo.com viewFreeBusy
revoked 0 permission
(didn't revoke any permission because group1@foo.com does not have a viewFreeBusy
grant, it only has a -viewFreeBusy grant)
mbox user1@example.com> rvp group group1@foo.com -viewFreeBusy
revoked:
group group1@foo.com -viewFreeBusy
mbox user1@example.com> rvp all viewFreeBusy
revoked:
all viewFreeBusy
mbox user1@example.com> rvp account user3@example.com invite
revoked:
account user3@example.com invite
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite group group2@example.com
-viewFreeBusy public
Note: when revoking a negative permission, "-" has to be prepended to the right,
otherwise the permission will not be revoked. See example above.
ZimbraServer/docs/accesscontrol.txt
OVERVIEW
========
Currently, we have "mail object" based access control mechanism in that
ACLs are generally associated with a single object in a user's Mailbox,
for example, a folder or a tag. The ACLs for mail object based access
controls are persisted in the user's database, in the METADATA column on the
MAIL_ITEM row for the folder or tag. ZimbraServer/docs/acl.txt describes
"mail object" based access controls.
In addition to the above access control scheme, it is required that we
support access control on the account level, where permissions are
granted on the account level, instead of on individual folders or tags.
Implementation of account based access controls is not changing any aspect
of "mail object" based access controls. However many of the terminologies
and concepts are shared between the two.
This document describes the account based access control mechanism.
On a side note, the role based delegated admin feature in GnR will be built
on the same model.
RIGHTS
======
Unlike mail object based access controls, rights for account based controls
are defined on a "higher", or "functionality" level. For example, instead
of the generic combination of "read', 'write" rights that can be applied to
all mail objects, rights for account based access controls are like
"viewFreeBusy", "invite", ...
Currently, the following rights are supported:
- invite
- viewFreeBusy
zmmailbox helpPermissions command describes each rights in more details.
NEGATIVE RIGHTS
===============
Negative right are to specifically deny certain privileges to the "grantee".
Negative rights will take precedence over positive rights.
For example, if you granted "no invite" to user A, then invites from user A
would not be able to automatically book the target account's calendar for the
appointment. Regardless of what other grants for the same right is applied to
user A(e.g. allow all authed users).
GRANTEES
========
Like mail object based access controls, to avoid support calls:
(1) a user always has full, irrevocable rights to their own mailbox.
and
(2) administrators are allowed full access to everything on the system,
until we have a full-featured role based delegated admin implementation.
Rights can be granted(allowed or denied) to other principals.
The type of supported grantees are:
user - a Zimbra user
group - a Zimbra group(distribution list)
all-authed - all authed Zimbra usres
public - the public
CONFLICTING GRANTEES
====================
When more than one ACEs of an ACL on the same right match a grantee and all ACEs
don't agree on the same allow/deny for the right, the ACE with the most specific
match takes precedence; and if all matching ACEs are equally related to the grantee,
the negative ACE takes precedence.
example 1:
- ACL has:
. allow user A for right R
. deny group G for right R
- user A is in group G
=> user A will be allowed for right R, because user match is more specific than group match.
example 2:
- ACL has:
. allow group G1 for right R
. deny group G2 for right R
- group G2 is a member of group G1
- user A is a member of group G2
=> user A will be denied for right R, because G2 is a more specific match than G1.
example 3:
- ACL has:
. allow group G1 for right R
. deny group G2 for right R
- group G1 and G2 are not member of each other
- user A is in both group G1 and group G2
=> user A will be denied, because negative ACE takes precedence.
If multiple ACEs conflict for a right for the same grantee, this is a wrong setting, which
should not happen if all modification to ACLs are done via the supported granting/revoking
interfaces: SOAP and zmmailbox. If for any reason such ACL does exist (e.g.
via ldapmodify, or zmprov ma command(should we make zimberaACE immutable so
it cannot be modified by zmprov?)), the result is **unexpected**, depending on
which ACE is encountered first when we iterate through the ACL. We could've
spent more cycles detecting such settings and honor the negative ACE if there
is one, but currently the implementation choice is not to do so.
e.g. - ACL has:
. allow user A for right R
. deny user A for right R
=> user A could be allowed or denied for right R, randomly.
ACL STORAGE AND SERIALIZATION FORMAT
====================================
ACLs are persisted in LDAP in the multi-valued "zimbraACE" attribute on the
target LDAP entry. ACE stands for "access control entry", multiple ACEs makes
an ACL(access control list).
ACEs are serialized in LDAP in the following format:
[-]
grantee: For user and group grantees, zimbraId of the account/distribution list
For all-authed and public grantees, pseudo UUID recognized by the code.
grantee-type: usr | grp | all | pub
right: one of the supported right.
if a '-' (minus sign) is prepended to the right, it means the right is
specifically denied.
e.g. fe0e1a88-e6e3-4fe1-b608-3ab6ce50351f grp -viewFreeBusy
fd6227f2-87e6-4453-9ccc-16853a6f8d27 usr viewFreeBusy
00000000-0000-0000-0000-000000000000 all viewFreeBusy
99999999-9999-9999-9999-999999999999 pub invite
Note: zimbraACE should NOT be directly modified via zmprov or any LDAP tools.
They should only be modified via zmmailbox commands. See GRANTING TOOLS below.
GRANTING TOOLS
==============
Before WEB UI is available for granting, revoking, viewing rights, zmmailbox is the sole
tool that should be used for those tasks.
zmmailbox commands:
1. List all permission related commands
command: help permission
scope: any
example:
mbox> help permission
getPermission(gp) [opts] [right1 [right2...]]
-v/--verbose verbose output
grantPermission(grp) {account {name}|group {name}|all|public {[-]permission}}
listPermission(lp) [opts]
-v/--verbose verbose output
revokePermission(rvp) {account {name}|group {name}|all|public {[-]permission}}
2. List and describe all permissions that can be granted
command: listPermission(lp) [opts]
-v/--verbose verbose output
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> lp -v
invite: automatically add meeting invites from grantee to the target's calendar
e.g. (1) When user Y is invited to a meeting, an appt is added to his calendar
automatically(tentatively) only if invite is from A, B, C or anyone in group G.
(2) Conf room Y can only be booked by users A, B, C and group G.
viewFreeBusy: view free/busy
e.g. Free/busy for Y can only be seen by users A, B, C and group G.
3. Get rights currently granted.
command: getPermission(gp) [opts] [right1 [right2...]]
-v/--verbose verbose output
Optional right(s) can be specified to get only ACEs for those rights.
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite all
-viewFreeBusy account user2@example.com
-viewFreeBusy group groupX@example.com
viewFreeBusy all
viewFreeBusy public
mbox user1@example.com> gp invite
Permission Type Display
---------------- -------- -------
invite all
Note:
- grants are sorted by Permission, then type(from the most specific to the least specific:
account, group, all, public), then grantee display name.
- To be consistent with the modifyFolderGrant(mfg) command, which is for mail object based permissions,
grantee types are displayed as account(for user grantee), group(for group grantee), all(for all-authed
grantee), and public(for public grantee).
4. Grant(allow or deny) a right to a grantee or a group of grantee.
To deny a right, put a '-' in front of the right.
command: grantPermission(grp) {account {name}|group {name}|all|public {[-]right}}
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> grp account user3 invite
granted:
account user3@example.com invite
mbox user1@example.com> grp group group1@foo.com -viewFreeBusy
granted:
group group1@foo.com -viewFreeBusy
mbox user1@example.com> grp group group2 invite
granted:
group group2@example.com invite
mbox user1@example.com> grp all viewFreeBusy
granted:
all viewFreeBusy
mbox user1@example.com> grp public -viewFreeBusy
granted:
public -viewFreeBusy
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite account user3@example.com
invite group group2@example.com
-viewFreeBusy group group1@foo.com
-viewFreeBusy public
viewFreeBusy all
Note:
(1) if domain is not given for account or group grantee, the domain of the selected
mailbox will be used.
(2) if a grantee currently has a grant(positive or negative) for a right, granting
to the same grantee with a different privilege overwrite the grant. For example,
if user A currently is allowed the right to invite, "grp account A -invite" will
change the grant(i.e. ACE) from allowed to denied.
(3) to complete remove a grant(i.e. an ACE) from a grantee, use the revokePermission(rvp)
command, see 5. below.
5. Revoke a right previously granted to a grantee or a group of grantees.
To revoke a denied right, put a '-' in front of the right.
command: revokePermission(rvp) {account {name}|group {name}|all|public {[-]right}}
scope: after a mailbox is selected
example:
mbox> sm user1@example.com
mailbox: user1@example.com, size: 0 B, messages: 0, unread: 0
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite account user3@example.com
invite group group2@example.com
-viewFreeBusy group group1@foo.com
-viewFreeBusy public
viewFreeBusy all
mbox user1@example.com> rvp group group1@foo.com viewFreeBusy
revoked 0 permission
(didn't revoke any permission because group1@foo.com does not have a viewFreeBusy
grant, it only has a -viewFreeBusy grant)
mbox user1@example.com> rvp group group1@foo.com -viewFreeBusy
revoked:
group group1@foo.com -viewFreeBusy
mbox user1@example.com> rvp all viewFreeBusy
revoked:
all viewFreeBusy
mbox user1@example.com> rvp account user3@example.com invite
revoked:
account user3@example.com invite
mbox user1@example.com> gp
Permission Type Display
---------------- -------- -------
invite group group2@example.com
-viewFreeBusy public
Note: when revoking a negative permission, "-" has to be prepended to the right,
otherwise the permission will not be revoked. See example above.
Compartmentalized groups or locations sharing a domain
Pic of the simple way preferences > calendar tab:
http://i31.tinypic.com/2lvizcg.jpg />
So you could apply it on a dist list, you can also prevent that dist list from receiving mail so it's not a mailing list - just a group.
http://i31.tinypic.com/2lvizcg.jpg />
So you could apply it on a dist list, you can also prevent that dist list from receiving mail so it's not a mailing list - just a group.
Compartmentalized groups or locations sharing a domain
Hi Mike,
Thanks for your replies. So is that screen shot from the up and coming version 5.0.7 then?
Thanks for your replies. So is that screen shot from the up and coming version 5.0.7 then?
-
Russianspi
- Advanced member
- Posts: 84
- Joined: Fri Sep 12, 2014 10:43 pm
Compartmentalized groups or locations sharing a domain
Hi Mike. Sorry to piggyback on an old thread, but this seemed like the appropriate place. I've just noticed (and I don't know how I've missed it for the past year) that if you share something internally, you can share it with a user or a GROUP. Very cool...except I don't see a place for creating a group. Is this another name for a distribution list? Or am I just really missing something? And if it is a distribution list, and it changes, are changes in the list reflected in sharing permissions? Thanks!